Las matemáticas de la latencia: lo que impone la física
La luz en el vacío viaja a 299.792 km/s. La luz en fibra óptica viaja a aproximadamente 2/3 de eso: unos 200.000 km/s, o aproximadamente 5 ms por cada 1.000 km de ida. El RTT es el doble: ~10 ms por cada 1.000 km de fibra. Las rutas reales suelen ser entre 1,3 y 2 veces la distancia ortodrómica, así que añada latencia adicional por las realidades del enrutamiento.
La luz se ralentiza en el vidrio por el índice de refracción. El índice de refracción de la fibra monomodo es de aproximadamente 1,467, así que la velocidad de la luz en fibra es c/1,467 ≈ 204.300 km/s. Esto da una latencia de ida de unos 4,9 ms por cada 1.000 km de fibra y un RTT de 9,8 ms. Es un suelo físico inquebrantable: ninguna ingeniería del proveedor supera la velocidad de la luz. Una regla práctica más útil para planificación: presupueste 1 ms por cada 100 km de ida, más 1-2 ms por cada salto de switching y enrutamiento. Los cables submarinos de larga distancia están bien diseñados y se acercan al mínimo teórico (Londres-Nueva York está en torno a 70 ms RTT, cerca del límite ortodrómico de 5.500 km). Las rutas de última milla y dentro de la ciudad suelen rondar los 5-15 ms por saltos de routers y geometría de peering del ISP, no por la distancia.
Estimaciones reales de RTT entre grandes ciudades
Tiempos aproximados de ida y vuelta (RTT completo) entre los principales hubs de hosting en 2026: Londres-Ámsterdam ~10 ms, Londres-Frankfurt ~15 ms, Londres-Nueva York ~70 ms, Nueva York-San Francisco ~70 ms, Frankfurt-Singapur ~160 ms, Londres-Sídney ~250 ms, Tokio-San Francisco ~100 ms. Son valores típicos de mejor caso de fibra medidos TCP a TCP entre peers de centros de datos.
Estas cifras provienen de los datos públicos de peering publicados por los principales IXP (LINX, AMS-IX, DE-CIX, KINX) y de grandes atlas de latencia (RIPE Atlas, WonderNetwork, Cloudping). Su RTT real variará entre un 10 % y un 30 % según la hora del día, las relaciones de peering entre su proveedor y el ISP del usuario, y la ruta concreta de cable submarino utilizada. Los valores anteriores son típicos, no garantizados, y suponen ambos extremos en centros de datos con tránsito de varios Tbps. Las conexiones de última milla residenciales añaden otros 5-30 ms encima del suelo entre centros de datos.
| De | A | Distancia (ortodrómica) | RTT típico |
|---|---|---|---|
| Londres | Ámsterdam | 360 km | ~10 ms |
| Londres | Frankfurt | 640 km | ~15 ms |
| Londres | París | 340 km | ~10 ms |
| Frankfurt | Varsovia | 900 km | ~20 ms |
| Londres | Nueva York | 5.570 km | ~70 ms |
| Nueva York | Miami | 1.760 km | ~30 ms |
| Nueva York | San Francisco | 4.140 km | ~70 ms |
| San Francisco | Tokio | 8.280 km | ~100 ms |
| Frankfurt | Singapur | 10.290 km | ~160 ms |
| Londres | Sídney | 16.990 km | ~250 ms |
| Frankfurt | Bombay | 6.580 km | ~110 ms |
| São Paulo | Miami | 6.580 km | ~120 ms |
Residencia de datos: RGPD, CLOUD Act y el resto
Los datos personales de la UE/EEE están sujetos al RGPD (Reglamento (UE) 2016/679), que restringe las transferencias fuera del EEE sin garantías específicas. La US CLOUD Act (2018) permite a las autoridades estadounidenses obligar a los proveedores con sede en EE. UU. a entregar datos con independencia del lugar físico de almacenamiento. Rusia y China tienen sus propios regímenes de localización de datos. Elija una región de centro de datos que se alinee con las jurisdicciones de sus usuarios y con sus obligaciones contractuales.
El RGPD (en vigor desde mayo de 2018) trata como reguladas todos los datos personales de residentes en la UE o el EEE —nombre, correo, dirección IP, datos de comportamiento— con independencia de dónde tenga su sede el responsable. Las transferencias transfronterizas requieren una decisión de adecuación, Cláusulas Contractuales Tipo o Normas Corporativas Vinculantes. Las excepciones del artículo 49 son estrechas. La sentencia Schrems II (Tribunal de Justicia de la UE, julio de 2020) anuló el Privacy Shield y endureció considerablemente las garantías de transferencia. La US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) permite a las autoridades federales estadounidenses obligar a cualquier proveedor con sede en EE. UU. a producir los datos almacenados, aunque estén en un servidor en Frankfurt. Esto crea tensión para los clientes europeos que usan proveedores de hosting con sede en EE. UU., con independencia del centro de datos físico. La Ley Federal Rusa n.º 242-FZ exige que los datos personales de ciudadanos rusos se traten inicialmente en servidores físicamente en Rusia. La PIPL china (Personal Information Protection Law, en vigor desde noviembre de 2021) exige localización para operadores de infraestructura crítica de información y para procesadores de datos de gran volumen. A ningún régimen le importa dónde se ejecuten sus servidores de aplicación; a todos les importa dónde se almacenan y procesan los datos personales.
Cuándo tiene sentido multirregión
Multirregión está justificado cuando tiene usuarios geográficamente distribuidos con requisitos de latencia inferiores a 100 ms, cuando tiene obligaciones regulatorias de residencia de datos en varias jurisdicciones o cuando el riesgo de caída en una sola región es inaceptable. Rara vez está justificado para proyectos personales, SaaS de bajo tráfico con usuarios en una sola región o cargas donde la complejidad de ingeniería supera al beneficio de latencia.
Multirregión añade tres costes concretos. Primero, complejidad de ingeniería: replicación de datos (con consistencia eventual o sincronía global), lógica de enrutamiento (geo-DNS, anycast, failover regional) y observabilidad entre regiones multiplican la superficie operativa. Segundo, coste de infraestructura: al menos el doble de cómputo y almacenamiento, más las tarifas de tránsito interregional que cobran por GB los proveedores cloud. Tercero, compromisos de consistencia: las escrituras síncronas globales están físicamente limitadas por las matemáticas de latencia de la sección anterior, así que la mayoría de los diseños multirregión aceptan alguna forma de consistencia eventual. Las justificaciones que merecen ese coste: usuarios reales distribuidos por continentes donde más de 200 ms de latencia hunden la conversión, requisitos de RTO subsegundo en recuperación ante desastres, obligaciones regulatorias de mantener datos UE en la UE y datos US en EE. UU. simultáneamente, o requisitos activo-activo donde la caída de un único centro de datos debe ser invisible. La mayoría de cargas en producción no la necesitan; muchos diseños se sobreingenian hacia ella.
Árbol de decisión: cómo elegir una región
Paso 1: identifique dónde vive el 80 % de sus usuarios (analítica, logs de CDN, mercado objetivo). Paso 2: elija la región de hosting más cercana. Paso 3: compruebe que la jurisdicción legal coincide con sus obligaciones de residencia de datos. Paso 4: añada una segunda región solo si el paso 1 revela un segundo grupo de usuarios a más de 100 ms de RTT del primero o si HA/DR lo exigen.
Recorra el árbol con honestidad. Para una típica SaaS centrada en Europa con usuarios principalmente en Alemania, Francia, Reino Unido y Países Bajos, un único centro de datos en Europa Occidental (Frankfurt, Ámsterdam o Londres) mantiene a cada usuario por debajo de 30 ms de RTT y satisface el RGPD limpiamente. Para un producto B2B centrado en EE. UU. con usuarios desde Boston a Los Ángeles, un único centro de datos en US East (Ashburn, NYC) mantiene a los usuarios de la costa este por debajo de 20 ms y a los de la costa oeste por debajo de 80 ms: malo para gaming, bien para la mayoría de SaaS. Para productos verdaderamente globales (apps web con usuarios en cada continente), una región principal más una CDN con presencia global de borde suele ganar a ejecutar activo-activo en tres centros de datos. Para productos con requisitos estrictos de residencia de datos entre jurisdicciones (un plano de datos UE-only y otro US-only), multirregión se vuelve obligatorio independientemente de la latencia.
Atajos de cumplimiento: certificaciones que sí significan algo
Busque ISO/IEC 27001 (gestión de seguridad de la información), SOC 2 Tipo II (controles operativos auditados a lo largo del tiempo, no en un único momento) y PCI DSS Nivel 1 (datos de pago) si aplican. Para clientes UE, busque acuerdos de tratamiento de datos (DPA) RGPD explícitos y una lista clara de subprocesadores. El marketing genérico de "seguridad de nivel empresarial" sin certificaciones nombradas es esencialmente irrelevante.
Tres certificaciones tienen peso real. ISO/IEC 27001:2022 es el estándar internacional para sistemas de gestión de seguridad de la información y exige una auditoría independiente y auditorías de vigilancia continuas. SOC 2 Tipo II audita los controles de una organización a lo largo de una ventana de observación de 6-12 meses, distinguiéndose del Tipo I (puntual). PCI DSS aplica si maneja tarjetas de pago; el Nivel 1 es para organizaciones que procesan más de 6 millones de transacciones al año. Para clientes europeos, el DPA del RGPD (acuerdo de tratamiento de datos) es contractualmente vinculante y especifica exactamente qué puede y qué no puede hacer el proveedor con sus datos. Más allá, busque informes de transparencia (¿con qué frecuencia recibe el proveedor solicitudes de las autoridades?), una lista publicada de subprocesadores (terceros que tocan sus datos) y garantías claras de eliminación de datos al terminar el contrato. Frases genéricas como "seguridad de nivel bancario" o "cifrado de grado militar" no le dicen nada: el algoritmo AES-256 subyacente es el mismo en todas partes.