DynamoDB Global Tables

Una global table es una sola tabla de DynamoDB replicada en varias regiones de AWS, donde cada réplica admite escritura. DynamoDB las mantiene sincronizadas automáticamente — obtienes lecturas y escrituras locales de baja latencia en cada región más recuperación ante desastres entre regiones, sin tener que gestionar tu propia replicación.

En el escenario del registro de auditoría, un cliente de la UE exige que sus datos residan en eu-west-1, mientras que el resto corre en us-east-1. Y al ser un registro crítico para el cumplimiento normativo, necesita sobrevivir a una caída regional completa. Una global table responde a ambas cosas con una sola funcionalidad.

¿Qué son las DynamoDB Global Tables?

Las DynamoDB Global Tables son una sola tabla replicada en varias regiones de AWS, donde cada réplica admite lectura y escritura. DynamoDB las sincroniza automáticamente mediante replicación asíncrona de consistencia eventual, resolviendo los conflictos con el criterio last-writer-wins. Obtienes lecturas y escrituras locales de baja latencia por región más recuperación ante desastres entre regiones, lo que respalda el SLA de disponibilidad del 99,999 % de DynamoDB.

• Multirregión, activo-activo. Cada réplica es totalmente legible y escribible; las escrituras en cualquier región se propagan a las demás.
• La replicación es asíncrona y de consistencia eventual entre regiones — normalmente en menos de un segundo, pero no instantánea.
• Los conflictos se resuelven last-writer-wins. Las escrituras concurrentes sobre el mismo Item en dos regiones se reconcilian quedándose con la más reciente.
• Respalda el SLA de disponibilidad del 99,999 % — una global table multirregión es la configuración de máxima disponibilidad de DynamoDB.

El problema: una sola región no basta

Una tabla de una sola región tiene dos límites que el registro de auditoría no puede aceptar. Primero, la residencia de los datos: los eventos de un cliente de la UE deben almacenarse en la UE, pero tu app corre en EE. UU. Segundo, la recuperación ante desastres: si us-east-1 sufre una caída, un registro de auditoría de una sola región queda ilegible e inescribible mientras dure — justo cuando más necesitas el registro de lo que pasó.

Construir cualquiera de las dos cosas por tu cuenta — replicación entre regiones, failover, gestión de conflictos — es un proyecto grande y propenso a errores. Las global tables lo convierten en una opción de configuración.

Cómo funcionan las global tables

Añades una región de réplica a la tabla; DynamoDB crea una copia ahí y mantiene sincronizadas todas las réplicas. Según las FAQ de AWS DynamoDB, las global tables proporcionan replicación multirregión con hasta un 99,999 % de disponibilidad, y la réplica de cada región sirve lecturas y escrituras locales.

Dos reglas de consistencia definen el comportamiento:

• La replicación entre regiones es asíncrona. Una escritura en us-east-1 se confirma localmente y luego se propaga a eu-west-1 — normalmente en menos de un segundo, pero una lectura en la otra región justo después de una escritura puede no verla todavía. (Las lecturas fuertemente consistentes siguen funcionando, pero solo dentro de una sola región.)
• Los conflictos son last-writer-wins. Si el mismo Item se escribe en dos regiones casi al mismo tiempo, DynamoDB conserva la escritura con la marca de tiempo más reciente y descarta la otra.

Un ejemplo práctico: una réplica de la UE que además es DR

Añades eu-west-1 como réplica de la tabla de registro de auditoría. Ahora:

La app del cliente de la UE escribe en la réplica local eu-west-1 y lee de ella — baja latencia y datos residentes en la región. La misma replicación que satisface la residencia hace doble función como recuperación ante desastres: si us-east-1 se cae, la réplica eu-west-1 sigue conservando el registro completo y sirve tráfico; haces failover a ella.

Como el registro de auditoría es append-only y particionado por tenant, last-writer-wins es prácticamente un no-problema aquí — los eventos de un tenant dado se escriben desde una región y las claves de evento son únicas, así que rara vez dos regiones compiten por el mismo Item. Eso no es suerte; es por lo que un registro append-only es uno de los encajes más limpios para las global tables. Un contador mutable, en cambio, requeriría cuidado bajo escrituras concurrentes entre regiones.

Hazlo en DynoTable

Después de añadir una réplica quieres confirmar que los datos realmente aterrizaron en la nueva región y coinciden con el origen — que la réplica de la UE de verdad contiene los eventos de acme, con los atributos correctos, y no va con retraso.

DynoTable se conecta a cualquier región con sus propias credenciales, así que puedes apuntar una ventana a us-east-1 y otra a eu-west-1 y comparar los Items del mismo tenant lado a lado para verificar la replicación.

Puedes prototipar las consultas por región que ejecutarás contra cada réplica en el DynamoDB Expression Builder.

Trampas y próximos pasos

• No leas tu propia escritura entre regiones. El retraso de replicación significa que una escritura en una región puede no aparecer en otra durante ~un segundo. No escribas en EE. UU. y leas de inmediato desde la UE esperando verla; la consistencia fuerte es solo dentro de una región.
• Last-writer-wins descarta datos en silencio. Para Items mutables escritos de forma concurrente en dos regiones, el perdedor se descarta sin error. Los diseños append-only o de un único escritor por Item (como este registro de auditoría) evitan el problema; el estado mutable compartido necesita un diseño consciente de los conflictos.
• Cada réplica cuesta. Cada región almacena una copia completa y factura su propia capacidad y almacenamiento — una réplica aproximadamente duplica el coste. Añade regiones por una necesidad real de residencia o DR, no por defecto.
• Las copias de seguridad son por réplica. Una global table restaurada se convierte en una tabla independiente — planifica la recuperación por región. Ver copias de seguridad y recuperación a un punto en el tiempo.

Las global tables protegen contra la pérdida de una región. La última preocupación operativa es protegerse contra la pérdida de datos — un deploy malo o un borrado accidental — con copias de seguridad y recuperación a un punto en el tiempo.

Descargar DynoTable para conectarte a varias regiones y verificar que las réplicas de tu global table contienen los mismos datos.