Planteamiento y contexto
Un servicio de pedidos, preferencias o inventario debe ofrecer lecturas y escrituras locales en varias Regiones. Compara DynamoDB Global Tables MREC (consistencia eventual multirregión) con MRSC (consistencia fuerte multirregión) y explica el enrutamiento, los conflictos, la conmutación por error, la capacidad y la recuperación. La entrevista evalúa los límites operativos y de consistencia, no simplemente el copiado de una base de datos a otra ubicación.
Global Tables ofrece replicación multirregión y multiactiva administrada: cualquier réplica puede atender lecturas y escrituras. MREC es la opción predeterminada y se replica de forma asíncrona; cuando el mismo elemento se modifica casi simultáneamente en diferentes Regiones, DynamoDB lo resuelve a nivel de elemento mediante una regla de "el último escritor gana" (LWW) basada en una marca de tiempo interna. MRSC replica sincrónicamente a al menos otra Región antes de confirmar una escritura, y las lecturas fuertemente consistentes en cualquier réplica devuelven el valor más reciente; requiere exactamente tres Regiones (tres réplicas, o dos réplicas más un testigo).
Qué está evaluando el entrevistador
Una respuesta sólida descompone las invariantes de negocio en elementos, claves de partición y transacciones entre elementos antes de elegir un modo a partir del RPO, la latencia de escritura y las garantías de lectura. Espera preguntas sobre la pérdida silenciosa de datos bajo LWW, la restricción de tres Regiones de MRSC, la visibilidad de transacciones MREC entre Regiones y el ordenamiento durante la restauración tras fallos (failback).
Decir únicamente “habilitar la replicación multirregión” es insuficiente. Explica los endpoints de la Región local, cómo evitar escrituras dobles en un mismo elemento, cómo monitorear ReplicationLatency y cómo manejar eliminaciones, reintentos y eventos duplicados.
Preguntas para aclarar primero
Invariantes y forma del conflicto
Pregunta si los estados de los pedidos pueden retroceder, si el inventario debe ser linealizable y si un elemento puede editarse concurrentemente en múltiples Regiones. Los campos fusionables de forma independiente pueden ser elementos separados o subregistros versionados. La atomicidad entre campos exige afrontar que las transacciones MREC son atómicas únicamente en la Región donde se invocan y no se replican como una sola transacción.
RPO, latencia y cantidad de Regiones
Aclara el RPO, la latencia de escritura P99, el tiempo de conmutación por error y las Regiones compatibles. MREC puede usar cualquier número de Regiones disponibles y normalmente se propaga en menos de un segundo; MRSC sacrifica algo de latencia de escritura para ofrecer lecturas fuertes entre Regiones y un objetivo de RPO cero, requiriendo a la vez tres Regiones.
Titularidad de escritura y recuperación
Decide si las escrituras son verdaderamente multiactivas o si cada inquilino tiene una Región de origen con réplicas de lectura en otros lugares. Si el negocio no puede aceptar LWW, usa IAM o enrutamiento para restringir a los escritores y definir la autoridad para la toma de decisiones sobre conflictos durante la recuperación en lugar de delegar la semántica a la replicación.
Respuesta de 30 segundos
“Elijo el modo a partir de las invariantes de negocio: los decrementos de inventario y las lecturas fuertes entre Regiones apuntan a MRSC, mientras que las cargas de trabajo que toleran una breve obsolescencia y priorizan la latencia de escritura local usan MREC por defecto. MREC es asíncrono y aplica LWW a nivel de elemento, por lo que asigno cada pedido o inquilino a una Región de origen y agrego escrituras condicionales, claves de idempotencia y versiones explícitas; los estados no fusionables no dependen de LWW. Cada solicitud utiliza su endpoint local y el tráfico se traslada en el borde de la aplicación durante una falla regional. Monitoreo ReplicationLatency, errores de replicación y fallas de escrituras condicionales, y luego reproduzco y audito la recuperación usando versiones, eventos y reglas de negocio”.
Solución paso a paso
Paso 1: Elegir un modo de consistencia
MREC es el predeterminado, admite cualquier número de Regiones y es eventualmente consistente, adaptándose a preferencias, catálogos y modelos de lectura tolerantes a datos obsoletos. MRSC replica sincrónicamente una escritura a al menos otra Región antes de responder con éxito; las lecturas fuertes en cualquier réplica ven el valor más reciente. Requiere exactamente tres Regiones y no admite operaciones de transacción. El modo se elige en el momento de la creación: las réplicas no pueden mezclar modos y la tabla no se puede cambiar después.
Paso 2: Definir la topología de escritura
Las aplicaciones deben utilizar el endpoint de DynamoDB en su Región local. Las escrituras multiactivas son apropiadas únicamente cuando el negocio puede resolver conflictos concurrentes. Los objetos con restricciones fuertes, como pedidos e inventario, pueden usar escrituras en la Región de origen con lecturas en otros lugares, o particiones de un solo escritor por inquilino o pedido. Las llamadas entre Regiones añaden latencia y superficie de falla; el cambio de tráfico pertenece al punto de entrada o capa de enrutamiento de la aplicación.
Paso 3: Restringir los conflictos bajo MREC
MREC utiliza LWW con marca de tiempo interna para actualizaciones casi concurrentes sobre un mismo elemento. Las réplicas convergen, pero los cambios de negocio descartados no se convierten automáticamente en trabajo de compensación. Usa expresiones de condición para las versiones e incluye un ID de solicitud idempotente. Persiste eventos de solo anexado (append-only) o registros de conflictos para estados que no se pueden sobrescribir. Representa las eliminaciones con un marcador de exclusión (tombstone) o estado explícito para que una actualización obsoleta no pueda resucitar un objeto eliminado.
Paso 4: Manejar transacciones y reintentos
En MREC, TransactWriteItems es atómico únicamente en la Región invocada; otras réplicas pueden observar temporalmente efectos parciales, por lo que una lectura entre Regiones no constituye una confirmación de transacción. Los reintentos deben distinguir entre fallas condicionales, limitación de tasa (throttling) y retraso de replicación, utilizando retroceso exponencial acotado y claves de idempotencia. MRSC no admite operaciones de transacción, por lo que las invariantes entre elementos requieren un nuevo modelo o coordinación a nivel de servicio.
Paso 5: Planificar la conmutación por error y la recuperación
Monitorea la latencia de replicación, los errores de replicación, las fallas de escrituras condicionales, la Región de la solicitud y las versiones de negocio. Durante un aislamiento, traslada el tráfico de entrada a una Región en buen estado. Con MREC, primero pausa las escrituras sensibles a conflictos o reubica la Región de origen de los inquilinos, registrando la hora de corte y la última versión visible. Tras la recuperación, valida la convergencia con registros de eventos, versiones y reglas de negocio; réplicas idénticas por sí solas no demuestran un inventario o pedido correcto.
Paso 6: Capacidad, seguridad y gobernanza
Evalúa la capacidad de lectura/escritura, el escalado automático y las cuotas para cada réplica. Una nueva réplica hereda la configuración de capacidad de la Región de origen en el momento de su creación y se puede ajustar posteriormente. Habilita la protección contra eliminación por réplica, usa IAM para restringir las Regiones de escritura y las operaciones de tabla, y recuerda que la pérdida de permisos de KMS detiene la replicación correspondiente. Las Global Tables multicuenta admiten MREC, no MRSC, por lo que la propiedad de cuenta, Región y auditoría debe ser explícita.
Paso 7: Verificar y ensayar
Ensaya escrituras concurrentes en un mismo elemento en dos Regiones, reintentos condicionales, particiones, eliminaciones con actualizaciones tardías, picos de replicación, cortes de tráfico y failback. Verifica la convergencia eventual, los eventos de compensación completos y la reproducción a prueba de duplicados, correlacionando ReplicationLatency y los recuentos de conflictos con los ID de solicitud. Las pruebas de carga deben reflejar distancias reales entre Regiones y modos de capacidad; la latencia de una sola máquina no es una estimación válida entre Regiones.
Respuesta de muestra de alta calidad
Elijo el modo a partir de las invariantes. Los datos críticos que requieren lecturas fuertes entre Regiones y un objetivo de RPO cero pueden usar MRSC, aceptando exactamente tres Regiones, mayor latencia de escritura y la ausencia de operaciones de transacción. Los catálogos y las preferencias pueden usar MREC. Debido a que el LWW asíncrono a nivel de elemento no puede fusionar la semántica de negocio, los pedidos y el inventario utilizan escrituras únicas en la Región de origen del inquilino o pedido, expresiones de condición, versiones y claves de idempotencia. Los campos fusionables son elementos separados; las actualizaciones no fusionables se convierten en eventos de conflicto.
La aplicación utiliza endpoints locales y la capa de entrada ejecuta la conmutación por error regional. Monitoreo ReplicationLatency, fallas de replicación y de escrituras condicionales, y diferencias de versión, con retroceso acotado para limitación de tasa y retrasos. Durante la recuperación, congelo las escrituras afectadas, valido la convergencia a partir de los registros de eventos y las reglas de negocio, y luego reabro el tráfico gradualmente. Audito la capacidad, la protección contra eliminación, IAM y KMS por réplica, y ensayo escrituras concurrentes, particiones, eliminaciones tardías y reproducción de duplicados.
Errores comunes
- Error: Asumir que Global Tables significa escrituras multiactivas sin restricciones. → Por qué falla: LWW en MREC puede descartar cambios de negocio no fusionables. → Solución: Asignar titularidad de escritura o diseñar versiones explícitas, eventos y compensación.
- Error: Tratar las transacciones de MREC como atómicas a nivel global. → Por qué falla: La atomicidad es local a la Región invocada y otras réplicas pueden ver efectos parciales. → Solución: Remodelar las invariantes entre Regiones y coordinar con eventos e idempotencia.
- Error: Cambiar de Región a ciegas tras un tiempo de espera (timeout). → Por qué falla: Las escrituras dobles amplifican los conflictos y el riesgo durante el failback. → Solución: Pausar o restringir escrituras, registrar versiones y luego conmutar a lo largo de los límites del inquilino o de negocio.
- Error: Equiparar la convergencia de réplicas con un inventario correcto. → Por qué falla: LWW resuelve la replicación, no el significado del negocio. → Solución: Validar con escrituras condicionales, registros de eventos, compensación y auditoría.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Cuándo elegirías MRSC?
Elige MRSC cuando las lecturas fuertes entre Regiones y un objetivo de RPO cero superen la importancia de la latencia de escritura y la flexibilidad de Regiones. Requiere exactamente tres Regiones, opcionalmente un testigo, y no admite transacciones. Si la carga de trabajo necesita cantidades arbitrarias de réplicas o replicación multicuenta, reevalúa MREC y la coordinación a nivel de servicio.
Pregunta de seguimiento 2: ¿Qué sucede si LWW sobrescribe un decremento de inventario?
No recuperes la cantidad a partir de LWW. Utiliza una expresión de condición y una versión para el decremento, asigna un propietario de escritura estable por producto o fragmento de inventario, y registra cada decremento como un evento idempotente. Un detector de conflictos compara las secuencias de eventos y emite una compensación o una cola para revisión humana; las lecturas verifican tanto la versión como el tiempo de visibilidad.
Pregunta de seguimiento 3: ¿Qué haces cuando aumenta el retraso de replicación en MREC?
Agrupa las alertas por Región de origen, Región de destino e impacto en el negocio. Limita las escrituras entre Regiones o devuelve a los inquilinos a su Región de origen para dejar de generar conflictos. Acota los reintentos del cliente, luego reconcilia versiones, eventos tardíos y marcadores de eliminación antes de restaurar las escrituras multiactivas. ReplicationLatency mide la propagación, no la corrección del negocio.
Pregunta de seguimiento 4: ¿Cómo pruebas el failback?
Ejercita el corte de tráfico, la recuperación de la Región antigua, la llegada de solicitudes a ambos lados y las eliminaciones tardías. Registra la Región, la versión y el ID de idempotencia para cada solicitud. Verifica que la Región antigua no pueda sobrescribir un estado más nuevo, que los eventos de conflicto sigan siendo rastreables y que la compensación sea repetible. Reporta RPO, RTO, recuento de conflictos e intervención humana.
Pregunta de seguimiento 5: ¿Por qué las réplicas no pueden mezclar MREC y MRSC?
El modo de consistencia es una configuración a nivel de tabla establecida al momento de su creación: las réplicas no pueden usar modos diferentes y la tabla no se puede cambiar después de haber sido creada. Un cambio en los requisitos requiere una tabla nueva, migración y una ventana controlada de doble escritura o reproducción, validando primero la capacidad, los permisos, la compatibilidad del cliente y el plan de reversión.