Planteamiento y casos de uso
Este es un problema de diseño de disponibilidad multirregión. La respuesta útil explica las decisiones de tráfico, la propagación de señales de salud, los límites de capacidad y datos durante una falla, y cómo se ensayan la conmutación por error (failover) y la conmutación por recuperación (failback).
Qué evalúa el entrevistador
- Si DNS, los proxies perimetrales y el enrutamiento de aplicaciones tienen responsabilidades y escalas de tiempo diferenciadas.
- Si el estado de salud utiliza señales en capas provenientes de múltiples observadores en lugar de un único endpoint.
- Si se calculan la capacidad de conmutación por error, las conexiones y los límites de tasa (rate limits).
- Si los datos con estado tienen una propiedad de escritura explícita, retraso de replicación y restricciones regionales.
- Si se controlan el cerebro dividido (split brain), el aleteo (flapping) y las cascadas en la conmutación por recuperación.
- Si se definen el RTO, el RPO, los SLO y la evidencia de simulacros.
Aclaraciones previas a responder
- ¿Qué regiones, pico de tráfico y modelo de falla de una sola región aplican?
- ¿Cuáles son las restricciones de RTO, RPO, residencia de datos y cumplimiento normativo?
- ¿Las solicitudes son en su mayoría lecturas sin estado, o incluyen escrituras y conexiones de larga duración?
- ¿El enrutamiento se realiza mediante DNS, Anycast, un proxy perimetral o una malla de servicios (service mesh)?
- ¿Qué flujos de usuario y dependencias deben cubrir las comprobaciones de salud?
- ¿Qué exigen el TTL de DNS del cliente, la migración de conexiones y las ventanas de conmutación por recuperación?
Estructura de respuesta en 30 segundos
“Definiría primero la falla regional, la carga máxima y el RTO/RPO. DNS o un punto de entrada perimetral pueden elegir candidatos basados en la latencia, pero solo las regiones que superen comprobaciones de salud en capas y cuenten con capacidad sobrante reciben tráfico. Durante una sobrecarga, aplicamos límites de tasa y degradamos por prioridad para que la región de respaldo sobreviva. Las escrituras siguen un límite de propiedad de datos con un retraso de replicación y una semántica de reintentos explícitos. Un controlador amortiguado cambia el peso gradualmente, y ensayamos, precalentamos y verificamos las métricas antes de la conmutación por recuperación”.
Análisis detallado paso a paso
Paso 1: Definir fallas y objetivos. Establezca el alcance de fallas de región, dependencias, red y plano de control, luego cuantifique el RTO, el RPO, los picos y los niveles de degradación.
Paso 2: Separar capas de decisión. DNS o un punto de entrada global maneja la elección gruesa de región; las capas perimetrales o de servicio manejan pesos en tiempo real, conexiones y límites locales. No haga que un solo plano de control soporte cada acción de falla.
Paso 3: Construir señales de salud. Combine sondeos de múltiples ubicaciones, flujos críticos de usuario, estado de dependencias, tasa de errores y capacidad. Ventanas consecutivas, ventanas de recuperación y decisiones tipo cuórum reducen el aleteo.
Paso 4: Proteger la capacidad. Reserve margen (headroom) para la conmutación por error y establezca límites de concurrencia, cola y tasa por región. Durante una falla, descarte el trabajo de baja prioridad antes de que el tráfico crítico cause una cascada.
Paso 5: Definir límites de datos. Explique el retraso de réplica, la propiedad de escritura, el manejo de conflictos, las claves de idempotencia y los reintentos entre regiones. El enrutamiento no puede hacer consistentes las escrituras no disponibles.
Paso 6: Ejecutar la conmutación por error. El controlador registra el motivo, la versión y la aprobación, reduce el peso de la región con fallas y desvía una cohorte pequeña antes de expandirse. Las conexiones de larga duración necesitan retroceso (backoff) y recuperación de sesión.
Paso 7: Ensayar la conmutación por recuperación. Precaliente la región recuperada, verifique métricas estables y comprobaciones de datos, y luego realice la conmutación por recuperación. Inyecte fallas regionales, de dependencias y del plano de control con regularidad y preserve evidencia medida de RTO/RPO.
Ejemplo de respuesta de alta calidad
“Dividiría cada región en una capa de entrada, servicios sin estado y una unidad de datos. El punto de entrada global selecciona candidatos por latencia, pero una región solo recibe tráfico cuando se superan las comprobaciones de flujo desde múltiples ubicaciones, los umbrales de error y el margen de capacidad. El controlador aplica un tiempo mínimo de permanencia y enfriamiento, enviando primero un 5% al respaldo. Si la concurrencia del respaldo alcanza su límite, protege el inicio de sesión y las escrituras mientras pausa los informes de baja prioridad. La propiedad del inquilino (tenant) determina la ubicación de escritura; los reintentos entre regiones llevan claves de idempotencia y exponen el retraso de replicación. Los simulacros validan el RTO, el RPO, el éxito de reconexión y las comprobaciones de datos tanto para la conmutación por error como por recuperación”.
Errores comunes
- Dibujar solo DNS y dos regiones → faltan capacidad y datos → añada salvaguardas en el controlador y propiedad de escritura.
- Eliminar una región tras un único sondeo fallido → el tráfico aletea → use ventanas, períodos de enfriamiento y múltiples señales.
- Asumir que el respaldo acepta todo el tráfico → la conmutación por error lo sobrecarga → calcule el margen disponible y la degradación por etapas.
- Tratar el TTL como tiempo de finalización → los clientes aún almacenan respuestas antiguas → incluya retrasos de resolución, conexión y perimetrales.
- Decir activo-activo sin reglas de conflicto → las escrituras quedan indefinidas → declare propiedad, replicación e idempotencia.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Qué sucede si el TTL de DNS es largo?
Utilice el perímetro para cambios de peso más rápidos e incluya el TTL, los cachés recursivos y la vida útil de las conexiones en el presupuesto de RTO; no prometa una transferencia instantánea.
Pregunta de seguimiento 2: ¿Qué sucede si fallan las comprobaciones de salud?
Utilice rutas de control independientes y sondeos desde múltiples ubicaciones, rastree la frescura y mantenga el último estado seguro o entre en un modo manual protegido cuando expiren las comprobaciones.
Pregunta de seguimiento 3: ¿Qué sucede si la capacidad de respaldo es insuficiente?
Reserve y precaliente capacidad, luego limite la tasa, degrade o encole por prioridad. Demuestre el límite máximo de una sola región mediante pruebas de carga.
Pregunta de seguimiento 4: ¿Cómo se previene el aleteo?
Utilice diferentes umbrales de falla y recuperación, un tiempo mínimo de permanencia, período de enfriamiento y aprobación, registrando un motivo para cada cambio de peso.
Pregunta de seguimiento 5: ¿Cómo se manejan los conflictos de escritura entre regiones?
Asigne la propiedad por inquilino o clave y utilice condiciones de versión o idempotencia. Si se requiere multi-escritura (multi-writer), defina reglas de conflicto y datos no fusionables.
Pregunta de seguimiento 6: ¿Cómo se demuestra que funciona?
Ejecute simulacros de fallas regionales, de dependencias, de red y del plano de control, y mida RTO, RPO, errores, capacidad recuperada, reconexiones y comprobaciones de datos.
Pregunta de seguimiento 7: ¿Cuándo se debe evitar el esquema multirregión?
Si la residencia de datos, la semántica de replicación, la capacidad operativa o el costo no permiten alcanzar el objetivo, utilice primero un diseño probado de una sola región con recuperación ante desastres. Multirregión no es algo automático.