Multirregión, recuperación ante desastres y edge computing

Por qué operar en más de una región

La Sección 0.7 (servidores y la nube) presentó las regiones (zonas geográficas separadas) y las zonas de disponibilidad (grupos independientes de centros de datos dentro de una región), y la sección 10.1 mostró cómo las organizan los proveedores. Operar en varias zonas de disponibilidad de una región es la base normal de cualquier sistema en producción: sobrevive a la pérdida de un centro de datos con poco costo adicional, porque las zonas están lo bastante cerca para la replicación síncrona. Operar en varias regiones es un paso mucho mayor, y solo hay tres buenas razones para darlo.

Latencia. La luz en la fibra óptica viaja a unos 200 000 km por segundo, así que un viaje de ida y vuelta entre Londres y Sídney (unos 17 000 km en línea recta) no puede tardar menos de unos 170 ms, y las rutas reales tardan bastante más. Una solicitud que necesita varios viajes de ida y vuelta a una región lejana se percibe lenta, por rápidos que sean los servidores. Servir a los usuarios desde una región cercana, o desde el borde, es la única solución.

Recuperación ante desastres. Las regiones enteras sí fallan, normalmente por una dependencia compartida más que por un desastre físico. El 19 y 20 de octubre de 2025, una condición de carrera en la automatización que gestiona los registros DNS de Amazon DynamoDB dejó su endpoint de US-EAST-1 con un registro DNS vacío; los errores de DynamoDB duraron unas tres horas, pero los fallos derivados al lanzar nuevas máquinas virtuales y en las comprobaciones de estado de los balanceadores de carga se prolongaron hasta la tarde siguiente. Todos los grandes proveedores han tenido incidentes regionales comparables. La recuperación ante desastres se prepara para ellos.

Residencia de datos. Los requisitos de residencia de datos, procedentes de la ley, de los reguladores o de los contratos con clientes, pueden exigir que ciertos datos se almacenen o se traten en jurisdicciones concretas. El propio RGPD (GDPR) restringe las transferencias de datos personales fuera del Espacio Económico Europeo en lugar de exigir el almacenamiento local, pero las normas sectoriales, las leyes nacionales y los contratos empresariales a menudo van más allá (consulta privacidad desde el diseño). La residencia obliga a menudo a diseños multirregión en los que los datos deliberadamente no se replican en todas partes.

La multirregión es cara: infraestructura duplicada, cargos por transferencia de datos entre regiones, una consistencia de los datos más difícil y unas operaciones y pruebas más complejas. Muchos equipos que creen necesitarla necesitan en realidad un buen diseño multizona, copias de seguridad probadas y una CDN.

Objetivos de recuperación y las cuatro estrategias

La Sección 2.5 (disponibilidad y fiabilidad) definió los dos números que guían todo diseño de recuperación ante desastres. El objetivo de tiempo de recuperación (RTO) es cuánto tiempo puede estar el servicio no disponible; el objetivo de punto de recuperación (RPO) es cuántos datos recientes se pueden perder, expresado como tiempo. Ambos los fija el negocio, idealmente a partir del costo de una hora de interrupción y de un pedido perdido, no de las preferencias de los ingenieros. Los valores más bajos cuestan más, y el costo se dispara cerca de cero.

El whitepaper de AWS Well-Architected Disaster Recovery of Workloads on AWS: Recovery in the Cloud describe cuatro estrategias, en orden creciente de costo y complejidad. Los nombres se usan ampliamente más allá de AWS y se aplican igual a Azure, a Google Cloud o a un par de centros de datos privados.

El propio whitepaper da una única cifra aproximada que abarca el RTO y el RPO de cada estrategia; la tabla los separa porque, con replicación continua, el RPO de pilot light y de warm standby lo determina el retardo de replicación y no cuánta parte de la aplicación está en marcha. Hay dos advertencias que se aplican a todas las columnas. La replicación no es una copia de seguridad: un borrado accidental, una mala migración o un ransomware se replican fielmente en segundos, así que hacen falta copias de seguridad de un momento dado, idealmente inmutables y en una cuenta separada, incluso en un diseño activo-activo. Y una estrategia que no se ha ensayado es una esperanza, no un plan. Los equipos que hacen un ejercicio de failover regional al menos unas cuantas veces al año descubren permisos que faltan, endpoints escritos en el código, certificados caducados y cuotas demasiado pequeñas en la región de recuperación, mientras todavía es barato encontrarlos.

Replicar datos entre regiones

Los servidores de aplicaciones sin estado son fáciles de ejecutar en dos lugares; los datos son la parte difícil, y los compromisos son los de la consistencia, CAP y PACELC a distancias continentales. La replicación síncrona entre regiones significa que cada escritura espera al menos un viaje de ida y vuelta largo, quizá de 70 a 150 ms o más, lo que es aceptable para unas pocas escrituras críticas y ruinoso para las que son muy frecuentes. La replicación asíncrona mantiene rápidas las escrituras, pero hace que la réplica vaya con retraso, y todo lo que no haya llegado cuando falle la región primaria se pierde: el retardo de replicación es el RPO efectivo.

Hay cuatro diseños de datos habituales. Región primaria única: todas las escrituras van a una región y las réplicas de otros lugares sirven lecturas y recuperación; es sencillo, pero los usuarios lejanos pagan la latencia de escritura y el failover implica promover una réplica (con los riesgos de split brain descritos en replicación y particionamiento). Región de origen por entidad: cada cliente, restaurante o tenant tiene una región de origen donde se escriben sus datos, lo que mantiene locales las escrituras y facilita la residencia, a costa del enrutamiento y de algunas operaciones ocasionales entre regiones. Múltiples escritores con resolución de conflictos: todas las regiones aceptan escrituras y los conflictos se fusionan, por ejemplo con last-writer-wins (la opción por defecto en las tablas globales de DynamoDB) o con tipos de datos replicados libres de conflictos; solo es seguro para datos en los que fusionar tiene sentido, como un carrito, y es peligroso para el dinero o el inventario. Bases de datos globalmente consistentes como Google Spanner o CockroachDB pagan la latencia del consenso en las escrituras para ofrecer consistencia fuerte entre regiones; Azure Cosmos DB permite a cada aplicación elegir entre cinco niveles de consistencia, de fuerte a eventual.

La mayoría de los sistemas reales combinan estos diseños según el conjunto de datos, tal como recomienda la sección 6.6: los pagos y el estado de los pedidos en una región primaria única o de origen, las cartas y los datos de los restaurantes replicados en todas partes para las lecturas, y la analítica enviada de forma asíncrona.

Failover, DNS y estabilidad estática

El tráfico se dirige entre regiones mediante el DNS o un balanceador de carga global. Con el failover (conmutación por error) basado en DNS, el servicio DNS comprueba el estado de cada región y devuelve la dirección de una que esté sana; su debilidad es la caché, porque los resolvedores y los clientes pueden conservar respuestas antiguas durante más tiempo que el TTL del registro. Los balanceadores de carga globales (por ejemplo, AWS Global Accelerator, Azure Front Door, el balanceador de carga externo global de Google Cloud o Cloudflare) usan direcciones anycast anunciadas desde muchas ubicaciones, de modo que los clientes mantienen una sola dirección y el proveedor desplaza el tráfico en segundos.

Decidir cuándo hacer el failover es más difícil que el mecanismo. El failover automático reacciona más rápido, pero puede dispararse por un fallo de la monitorización o por un breve corte de red, y hacer failover de una base de datos corre el riesgo de que dos primarios acepten escrituras. Por eso muchas organizaciones automatizan la detección y los pasos del failover, pero mantienen una decisión humana para iniciar un failover regional, con un runbook y un límite de tiempo. Volver a la región original tras el incidente (failback), incluida la resincronización de los datos escritos en la región de recuperación, también necesita un plan.

El incidente de octubre de 2025 ilustra un principio que la AWS Builders' Library llama estabilidad estática: un sistema debe seguir funcionando durante un fallo sin tener que hacer cambios en ese momento. Los sistemas que ya tenían suficiente capacidad en marcha superaron el problema; los que necesitaban lanzar nuevas instancias, o cuya recuperación dependía de acciones del plano de control en la región afectada, no pudieron recuperarse hasta que lo hizo la región. Para la recuperación ante desastres, esto aboga por la capacidad aprovisionada de antemano (warm standby en lugar de pilot light, para las rutas críticas), por un failover que dependa solo del plano de datos de la región sana, y por un DNS, una identidad y unos secretos que no vivan únicamente en la región de la que se huye.

Células: limitar el radio de impacto

Las regiones protegen frente a desastres regionales; sin embargo, la mayoría de las interrupciones las causan los propios cambios del sistema, las sobrecargas y las entradas envenenadas, que una segunda región con el mismo código y la misma configuración también sufrirá. La arquitectura basada en células limita el radio de impacto (blast radius) de esos fallos ejecutando muchas copias completas e independientes del sistema, llamadas células, cada una de las cuales atiende a un subconjunto fijo de clientes. Un router ligero asigna cada solicitud a su célula, normalmente por el identificador del cliente o del tenant. Las células no comparten nada en tiempo de ejecución: cada una tiene sus propias instancias de aplicación, colas y bases de datos.

Si una célula sufre un mal despliegue, un cliente con demasiada carga o una corrupción de datos, solo se ven afectados los clientes de esa célula: con 20 células, alrededor del 5% de ellos. Los despliegues avanzan célula a célula en oleadas, así que un mal lanzamiento se detecta en la primera célula. El diseño se describe en el whitepaper de AWS Well-Architected Reducing the Scope of Impact with Cell-Based Architecture (2023) y lo usan a gran escala los propios servicios de AWS y empresas como Slack. Una técnica relacionada, el shuffle sharding, da a cada cliente una combinación aleatoria de unos pocos workers entre muchos (con 8 workers y 2 por cliente hay 28 combinaciones), de modo que un cliente cuyas solicitudes hacen caer a los workers solo tumba su propia combinación, y la mayoría de los demás clientes comparten como mucho un worker con él.

Las células tienen un costo: más instancias y bases de datos que operar, operaciones entre células (informes sobre todos los clientes, mover un cliente de una célula a otra) que necesitan una maquinaria aparte, y un router y un servicio de mapeo que deben ser extremadamente sencillos y fiables. Encajan en grandes sistemas multitenant con claves de partición naturales; para una aplicación interna de un solo tenant son un exceso de ingeniería.

El borde: CDN y funciones en el borde

Entre los usuarios y las regiones está el borde (edge): los cientos de ubicaciones que operan las redes de distribución de contenidos como Akamai, Cloudflare, Fastly, Amazon CloudFront y Azure Front Door. Una CDN almacena en caché el contenido estático y cacheable (imágenes, scripts, páginas de cartas) cerca de los usuarios, siguiendo las reglas de caché de HTTP descritas en caché, y absorbe los picos de tráfico y muchos ataques de denegación de servicio antes de que lleguen al origen.

Las funciones en el borde (edge functions) van más allá y ejecutan código en esas ubicaciones: Cloudflare Workers, Fastly Compute, CloudFront Functions y Lambda@Edge, Akamai EdgeWorkers, y las funciones en el borde de plataformas como Vercel y Netlify. Cloudflare Workers ejecuta el código en isolates ligeros de V8, los entornos aislados que usan los motores de JavaScript para las pestañas del navegador, en lugar de en un contenedor por función, así que el arranque es muy rápido y muchos tenants comparten un proceso de forma segura. Este mismo curso se ejecuta en Cloudflare Workers. Buenos usos son el enrutamiento de solicitudes y la asignación de pruebas A/B, las comprobaciones de autenticación y la validación de tokens, las reglas de cabeceras y redirecciones, el redimensionado de imágenes, la personalización sencilla y los proxies de API que mantienen las claves secretas fuera del navegador.

Los límites son arquitectónicos. Las funciones en el borde tienen límites estrictos de tiempo de CPU y de memoria; el almacenamiento en el borde suele tener consistencia eventual (Workers KV de Cloudflare puede tardar un tiempo en propagar una escritura a todo el mundo) u ofrece consistencia fuerte solo para un único objeto coordinador, como hacen los Durable Objects; y el sistema de registro normalmente se queda en una región. Por eso un patrón habitual es leer en el borde, escribir en el origen: servir las cartas, las páginas de restaurantes y las comprobaciones de sesión desde el borde, y enviar los pedidos y los pagos a la región de origen.