Planteamiento y contexto
El entrevistador pregunta: “Nuestro SaaS B2B replica datos en dos regiones. ¿Deberían los clientes poder activar una conmutación cuando falla la región principal?” Suponga que los clientes no pueden operar la base de datos subyacente directamente y que el producto debe preservar el aislamiento de inquilinos (tenant isolation), la residencia de datos y la auditabilidad. Esto encaja en entrevistas de platform product manager, infrastructure product manager y technical program manager.
La prueba consiste en el establecimiento de límites del producto, no en una respuesta refleja de “la automatización es más rápida”. AWS posiciona los diseños multirregión para una resiliencia extrema, pero advierte que las dependencias entre regiones debilitan dicha postura; Google Cloud sostiene que la recuperación debe ser diseñada, construida y probada; Azure enmarca la elección en torno a los requisitos del negocio, RTO, RPO, costo y complejidad.
Qué evalúa el entrevistador
- ¿Puede transformar “los clientes quieren el control” en requisitos medibles de RTO, RPO, residencia y cumplimiento normativo?
- ¿Puede distinguir entre una conmutación automática de la plataforma, aprobada por un operador o solicitada por el cliente?
- ¿Puede nombrar modos de falla que involucren retraso de replicación (replication lag), split brain, almacenamiento en caché de DNS, cuotas y señales falsas?
- Una respuesta sólida delimita la operación a un plano de control de inquilinos con comprobaciones previas, aprobación, simulacros, auditoría y conmutación por recuperación (failback). Una respuesta débil expone un botón básico de conmutación por error sin restricciones.
Preguntas aclaratorias antes de responder
¿Qué falla estamos resolviendo?
Una falla en la aplicación de un solo inquilino puede gestionarse mediante aislamiento o reinicio; una interrupción regional completa es el caso para la conmutación entre regiones. Si la necesidad es solo de latencia, un diseño multirregión podría no superar a un diseño multi-AZ más simple.
¿Cuáles son el RTO y el RPO?
La replicación asíncrona puede perder las escrituras más recientes. Un requisito de RPO cero no puede satisfacerse con un botón ordinario de réplica asíncrona. El RTO determina la capacidad activa en espera (warm capacity); el RPO determina si el retraso de replicación es aceptable.
¿Qué datos pueden salir de la región original?
La residencia, las claves de cifrado, las copias de seguridad y los registros modifican las regiones de destino elegibles. Una “región secundaria” no es automáticamente una región conforme a la normativa.
Una respuesta de 30 segundos
“Yo estructuraría la experiencia en niveles según el objetivo de disponibilidad, la pérdida de datos aceptable y las restricciones de residencia de cada inquilino. Normalmente, la plataforma debería conmutar de forma automática o con la aprobación de un operador a partir de señales de salud sólidas; solo los inquilinos que pasen las comprobaciones previas deberían enviar una solicitud de conmutación auditada, en lugar de promover una réplica directamente. La solicitud comprueba el retraso de replicación, la capacidad de destino, las claves, las versiones y las dependencias, y luego congela o drena las escrituras. Después de la conmutación, monitoreamos los errores, el estado de escritura y el RPO, y restauramos la operación normal solo después de cumplir los criterios de failback. Haría un simulacro con un conjunto reducido de inquilinos, compararía el tiempo de recuperación, las conmutaciones falsas y el impacto en los clientes, y luego decidiría si ampliar el acceso”.
Solución paso a paso
- Definir el contrato del producto. Trate la conmutación por error regional como una operación de recuperación ante desastres delimitada al inquilino. Establezca el RTO objetivo, el RPO máximo, las funciones no disponibles, el precio y las responsabilidades del cliente. Una réplica que no pueda cumplir el contrato no debe mostrarse como lista.
- Crear tres niveles de control. La automatización de la plataforma se adapta a señales de salud regionales inequívocas; la aprobación de un operador se adapta a dependencias compartidas con impacto en el negocio; una solicitud del cliente debe generar un comando restringido evaluado por políticas. Los clientes no deben editar DNS, promover bases de datos ni reproducir colas directamente.
- Ejecutar comprobaciones previas. Verifique el tiempo de puesta al día de la réplica, la cuota de destino, la versión de la aplicación, la disponibilidad de claves, el retraso de la cola (backlog), las dependencias externas y la residencia. Una comprobación fallida debe devolver un motivo procesable antes de aceptar la operación.
- Proteger la autoridad de escritura. Detenga o drene las escrituras en la región principal, registre la última posición confirmada y promueva exactamente una autoridad de escritura. Exponga la ventana desconocida creada por la replicación asíncrona; “replicado” no significa pérdida cero.
- Verificar y realizar la conmutación por recuperación (failback). Utilice transacciones sintéticas para inicio de sesión, lecturas, escrituras, tareas en segundo plano (jobs) y auditoría. Monitoree la tasa de errores, la posición de replicación, la antigüedad de la cola y el éxito del inquilino. Antes del failback, ponga al día la replicación en dirección inversa y simule conflictos para que la recuperación no cree dos escritores.
- Elegir un despliegue gradual. Comience con simulaciones de solo lectura para inquilinos internos o dispuestos a participar, luego con conmutación aprobada por un operador, y solo más adelante considere la automatización. Pause ante una condición de parada definida: conmutaciones falsas, incumplimiento del RPO, capacidad de destino insuficiente o falta de evidencia de auditoría.
Respuesta modelo
No entregaría a los clientes un botón sin restricciones. Primero confirmaría si necesitan un RTO entre regiones, qué RPO pueden aceptar y qué restricciones de residencia aplican. El producto puede exponer “solicitar conmutación por error”, pero la solicitud debe superar las comprobaciones de política del inquilino, posición de replicación, capacidad de destino, versión, claves y dependencias.
Durante la conmutación, la plataforma congela o drena las escrituras en la región principal, registra la última posición confirmada, promueve una réplica de escritura e indica la ventana de pérdida esperada y las funciones no disponibles. Posteriormente, las transacciones sintéticas verifican lecturas, escrituras, trabajos y auditoría. Medimos los errores, el estado de replicación y el tiempo de recuperación por inquilino. El failback comienza solo después de que la puesta al día inversa demuestre que no hay split brain.
Haría simulacros con inquilinos internos, añadiría aprobación del operador y consideraría la automatización solo después de contar con evidencia sólida. Si las conmutaciones falsas, el RPO o las comprobaciones previas de capacidad cruzan un umbral, se inhabilita el acceso activado por el cliente y se conserva el registro de auditoría. Esto brinda a los clientes visibilidad y un control delimitado sin transferirles el riesgo de la recuperación ante desastres.
Errores comunes
- Tratar la arquitectura multirregión como disponibilidad automática → ignora la promoción, las dependencias y el failback → documente RTO/RPO, simulacros y failback por componente.
- Permitir que los clientes promuevan la base de datos directamente → arriesga un split brain o impacto entre inquilinos → exponga un comando de inquilino auditado y ejecutado por política.
- Comprobar únicamente la salud regional → el estado de salud de DNS no prueba que los datos, las claves o la cuota estén listos → incluya posición de replicación, capacidad, versión, claves y dependencias.
- Prometer cero pérdida de datos → la replicación asíncrona tiene una ventana no confirmada → establezca el RPO, registre la última posición confirmada y muestre el rango de pérdida posible.
- Omitir el failback → la región principal recuperada puede generar escrituras duales y divergencia de datos (drift) → diseñe la puesta al día inversa, detección de conflictos y failback por etapas.
Preguntas de seguimiento y respuestas
¿Qué ocurre si el cliente exige RPO cero?
Explique que la replicación asíncrona no puede proporcionar RPO cero. Evalúe la replicación síncrona o escrituras duales a nivel de negocio, y luego recalcule la latencia, la disponibilidad, el costo y la consistencia. Si aún no se puede cumplir el objetivo, reemplácelo con una ventana medible de pérdida máxima.
¿Qué pasa si una señal de salud falsa activa la automatización?
Exija múltiples señales, una duración mínima y una ventana de cancelación humana. Para inquilinos de alto valor, entre en un estado congelado y verificado previamente antes de la promoción. Registre cada decisión y ajuste los umbrales utilizando la tasa de conmutaciones falsas y el tiempo de recuperación.
¿Qué ocurre si la región de destino no tiene capacidad tras la solicitud?
Compruebe previamente la cuota y la capacidad, y reserve un presupuesto o un plan de escalado automático para inquilinos críticos. En caso de fallo, devuelva el motivo y preserve el estado principal; no conmute a una región no preparada solo para mejorar la tasa de éxito del botón.
¿Se pueden eximir las reglas de residencia durante una interrupción?
No asuma una excepción. Incluya las regiones permitidas, las claves de cifrado y los límites de registros en el contrato y las políticas del inquilino. Si se prohíbe el movimiento transfronterizo, ofrezca resiliencia multi-AZ en la misma región o un modo degradado explícito.