La pregunta y cuándo aplica
Diseñe un coordinador que evalúe la salud regional, desvíe el tráfico cuando se cumplan ciertas reglas y restablezca el tráfico de forma segura tras la recuperación. Explique los planos de control y de datos, las señales, el estado de los datos, las aprobaciones, la auditoría y los simulacros.
AWS ARC describe los controles de enrutamiento como interruptores confiables del plano de datos y enfatiza que los mecanismos de conmutación por error deben funcionar durante un desastre. Kubernetes destaca las réplicas, la dispersión topológica y los presupuestos de disrupción. Los temas de entrevistas de software de Amazon hacen hincapié en la aplicación de conocimientos para resolver problemas de sistemas.
Esto difiere del diseño de un API gateway multirregión: el enfoque radica en el flujo de trabajo de decisión y recuperación, incluidos los falsos positivos, el split brain, la sincronización de datos y el failback.
Qué evalúan los entrevistadores
Buscan salud multiseñal, controles de enrutamiento resilientes, RTO/RPO y replicación explícitos, mecanismos de aislamiento (fencing) contra decisiones concurrentes, auditabilidad, simulacros y un plan de failback medible.
Preguntas para aclarar antes de responder
- ¿Cuáles son los objetivos de RTO, RPO, disponibilidad e intervención humana?
- ¿La falla es de accesibilidad regional, de una dependencia, de latencia, de despliegue o de corrupción de datos?
- ¿La región en espera es hot, warm o cold?
- ¿Qué datos se replican y qué escrituras pueden rechazarse?
- ¿Cómo reciben el nuevo enrutamiento el DNS, un gateway, Anycast o los clientes?
- ¿Quién puede asumir el control si la automatización falla?
- ¿Cómo se evitan las escrituras duales (dual writing)?
- ¿Qué condiciones de salud y de sincronización de datos condicionan el failback?
- ¿El alcance es para una nube específica o es un diseño abstracto?
Estructura de respuesta en 30 segundos
«Defino primero el RTO, el RPO y la preparación del standby. Cada región ejecuta su propio plano de datos; el coordinador solo publica estados de enrutamiento validados. La salud combina sondeos de negocio, dependencias, capacidad y retraso de replicación con señales tipo cuórum y amortiguación (dampening). Antes de cambiar, aíslo o degrado las escrituras, verifico el umbral de datos del standby y utilizo un control de enrutamiento de alta disponibilidad. Cada cambio de estado es auditable y reversible. El failback espera a que se restablezca la salud y la sincronización de datos, y luego comienza con una pequeña porción de tráfico».
Respuesta detallada, paso a paso
Paso 1: Definir modelos y objetivos de falla
Separe el deterioro de zona, la partición regional, la falla de dependencias, los despliegues defectuosos y la corrupción de datos. Asigne RTO/RPO al costo del standby, la replicación y la automatización.
Paso 2: Separar los planos de control y de datos
El plano de datos atiende solicitudes y ejecuta el enrutamiento. El plano de control calcula recomendaciones, aprobaciones y registros. La ejecución de la conmutación por error no debe depender de un plano de control que no esté disponible.
Paso 3: Construir las decisiones de salud
Combine el éxito de negocio, dependencias, latencia, retraso de replicación, capacidad y señales de los operadores. Un solo sondeo fallido crea un estado candidato; los umbrales sostenidos hacen avanzar el flujo de trabajo.
Paso 4: Ejecutar un cambio seguro
Utilice estados como listo (ready), candidato (candidate), aprobado (approved), cambiando (switching), estable (stable) y failback. Los arrendamientos (leases) o versiones de aislamiento (fencing) evitan operaciones concurrentes. Defina el aislamiento de escritura, el tiempo máximo de cambio y las acciones de detención.
| Etapa | Verificación clave | Acción ante fallas |
|---|---|---|
| Ready | Umbral de standby y replicación | Bloquear el cambio |
| Candidate | Falla multiseñal sostenida | Observar o aprobar |
| Switching | Enrutamiento, errores y capacidad | Pausar o revertir |
| Stable | Recuperación del negocio y escritor único | Completar |
| Failback | Salud de la región primaria y sincronización | Mantener activo el standby |
Paso 5: Manejar la consistencia y el split brain
Elija un escritor único, secuenciación global o resolución de conflictos. Durante una partición, rechace escrituras inseguras en lugar de aceptar escrituras no fusionables en ambas regiones. Registre el punto de corte y la brecha de datos.
Paso 6: Propagar rutas y proteger la capacidad
Explique la propagación por DNS, gateway o edge, incluidos el TTL, los cachés y los reintentos de los clientes. Precaliente la capacidad del standby y defina modos de limitación de tasa (throttling) y degradación.
Paso 7: Observar, auditar y transferir el control
Registre evidencia de salud, versión de reglas, operador, transiciones de estado y resultado de rutas. Genere alertas sobre tiempo de cambio, errores, retraso (lag), capacidad e indicios de escritura dual. Las acciones manuales deben estar autorizadas y ser idempotentes.
Paso 8: Realizar simulacros y ejecutar el failback de forma segura
Inyecte fallas y pruebe el tráfico por etapas. Antes del failback, verifique la salud de la región primaria, la sincronización de datos, la estabilidad de las dependencias y la capacidad. Desvíe primero un porcentaje pequeño y mantenga la opción de reversión rápida.
Ejemplo de respuesta de alta calidad
«Diseñaría dos regiones con un único escritor, un RTO de cinco minutos y un RPO de treinta segundos. Ambas regiones tienen un plano de datos completo; la región en espera mantiene cachés y capacidad precalentadas.
La salud combina el éxito de negocio, dependencias, retraso de replicación y capacidad. Tres ventanas consecutivas defectuosas generan un estado candidato; un lease y una versión de fencing monotónica permiten que solo un coordinador avance de estado. Antes del cambio, se aíslan las escrituras, se verifica el retraso del standby y un control de enrutamiento de alta disponibilidad traslada el tráfico. Se observan los errores y la latencia, con un umbral de reversión inmediata.
Las auditorías almacenan evidencias, reglas, aprobaciones y resultados de rutas. Simulacros mensuales prueban el almacenamiento en caché de DNS, los reintentos de clientes y la capacidad del standby. El failback espera la sincronización de datos, desvía el cinco por ciento primero y se detiene si surgen escrituras duales o latencia».
Errores comunes
- Mostrar dos regiones sin un responsable de la decisión.
- Usar un solo ping o métrica de infraestructura como indicador de salud del negocio.
- Automatizar sin aislamiento (fencing), amortiguación (dampening), aprobación o capacidad de reversión.
- Ignorar el TTL, los cachés y los reintentos de clientes.
- Permitir escrituras duales sin manejo de conflictos.
- Olvidar el precalentamiento y la capacidad del standby.
- Tratar la conmutación por error (failover) pero no el failback o los simulacros.
- Indicar RTO/RPO sin asociarlos a la replicación y los costos.
Preguntas de seguimiento y cómo responder
Pregunta de seguimiento 1: ¿Cómo maneja los falsos positivos?
Utilice múltiples señales, ventanas sostenidas y amortiguación (dampening). Ante una falla de baja confianza, se debe observar o degradar antes de cambiar.
Pregunta de seguimiento 2: ¿Qué sucede si el plano de control está caído?
Mantenga los interruptores de ejecución y las lecturas requeridas en un plano de datos de alta disponibilidad, predistribuya el estado seguro y limite las operaciones manuales auditadas.
Pregunta de seguimiento 3: ¿Qué ocurre si ambas regiones se convierten en primarias?
Utilice leases, fencing tokens o un árbitro externo. Si la propiedad de escritor único es incierta, rechace las escrituras.
Pregunta de seguimiento 4: ¿Qué pasa si la capacidad del standby es insuficiente?
Reserve capacidad, utilice degradación y limitación de tasa (throttling), y acepte solo tráfico crítico cuando no se pueda atender la carga completa.
Pregunta de seguimiento 5: ¿Por qué no automatizar todo?
Automatice las fallas reversibles y de alta confianza. Exija confirmación humana en casos de corrupción, split brain y eventos de baja confianza.
Pregunta de seguimiento 6: ¿Cómo demuestra que los simulacros funcionan?
Haga seguimiento del tiempo entre detección y recuperación, RPO, errores, capacidad, pasos manuales y resultados de reversión; transforme las deficiencias en mejoras asignadas a responsables concretos.