Global Tables do DynamoDB

Uma global table é uma única tabela DynamoDB replicada entre múltiplas regiões AWS, onde cada réplica é gravável. O DynamoDB as mantém em sincronia automaticamente — você ganha leituras e escritas locais de baixa latência em cada região além de recuperação de desastres entre regiões, sem rodar sua própria replicação.

No cenário do log de auditoria, um cliente da UE exige que seus dados vivam em eu-west-1, enquanto o resto roda em us-east-1. E, como um log crítico para conformidade, ele precisa sobreviver a uma queda total de região. Uma global table responde aos dois com um único recurso.

O que são as Global Tables do DynamoDB?

As Global Tables do DynamoDB são uma única tabela replicada entre múltiplas regiões AWS, onde cada réplica é legível e gravável. O DynamoDB as sincroniza automaticamente por replicação assíncrona de consistência eventual, resolvendo conflitos com last-writer-wins. Você ganha leituras e escritas locais de baixa latência por região, além de recuperação de desastres entre regiões, sustentando o SLA de disponibilidade de 99,999% do DynamoDB.

• Multi-região, ativo-ativo. Cada réplica é totalmente legível e gravável; as escritas em qualquer região se propagam para as outras.
• A replicação é assíncrona e de consistência eventual entre regiões — tipicamente em um segundo, mas não instantânea.
• Os conflitos são resolvidos com last-writer-wins. Escritas concorrentes ao mesmo item em duas regiões reconciliam para a mais recente.
• Ela sustenta o SLA de disponibilidade de 99,999% — uma global table multi-região é a configuração de maior disponibilidade do DynamoDB.

O problema: uma região não é suficiente

Uma tabela de região única tem dois limites que o log de auditoria não pode aceitar. Primeiro, residência de dados: os eventos de um cliente da UE precisam ser armazenados na UE, mas seu app roda nos EUA. Segundo, recuperação de desastres: se us-east-1 tiver uma queda, um log de auditoria de região única fica ilegível e não-gravável durante todo o período — exatamente quando você mais precisa do registro do que aconteceu.

Construir qualquer um deles você mesmo — replicação entre regiões, failover, tratamento de conflitos — é um projeto grande e propenso a erros. As global tables transformam isso em uma escolha de configuração.

Como as global tables funcionam

Você adiciona uma região de réplica à tabela; o DynamoDB cria uma cópia lá e mantém todas as réplicas em sincronia. Segundo as FAQs do DynamoDB da AWS, as global tables fornecem replicação multi-região com até 99,999% de disponibilidade, e a réplica de cada região atende leituras e escritas locais.

Duas regras de consistência definem o comportamento:

• A replicação entre regiões é assíncrona. Uma escrita em us-east-1 é confirmada localmente e então propagada para eu-west-1 — normalmente em um segundo, mas uma leitura na outra região logo depois de uma escrita pode ainda não vê-la. (Leituras com consistência forte ainda funcionam, mas apenas dentro de uma única região.)
• Os conflitos são last-writer-wins. Se o mesmo item for escrito em duas regiões quase ao mesmo tempo, o DynamoDB mantém a escrita com o timestamp mais recente e descarta a outra.

Um exemplo prático: uma réplica na UE que também é DR

Você adiciona eu-west-1 como réplica da tabela de log de auditoria. Agora:

O app do cliente da UE escreve e lê da réplica local eu-west-1 — baixa latência e dados residentes na região. A mesma replicação que satisfaz a residência funciona em dobro como recuperação de desastres: se us-east-1 cair, a réplica eu-west-1 ainda mantém o log completo e atende o tráfego; você faz failover para ela.

Como o log de auditoria é append-only e particionado por tenant, o last-writer-wins é essencialmente um não-problema aqui — os eventos de um dado tenant são escritos a partir de uma região e as chaves de evento são únicas, então duas regiões raramente disputam o mesmo item. Isso não é sorte; é por isso que um log append-only é um dos encaixes mais limpos para global tables. Um contador mutável, por contraste, precisaria de cuidado sob escritas concorrentes entre regiões.

Faça no DynoTable

Depois de adicionar uma réplica, você quer confirmar que os dados realmente chegaram à nova região e correspondem à origem — que a réplica da UE de fato contém os eventos do acme, com os atributos certos, e não está atrasada.

O DynoTable se conecta a qualquer região com suas próprias credenciais, então você pode apontar uma janela para us-east-1 e outra para eu-west-1 e comparar os itens do mesmo tenant lado a lado para verificar a replicação.

Você pode prototipar as consultas por região que vai rodar contra cada réplica no Construtor de Expressões do DynamoDB.

Armadilhas e próximos passos

• Não leia sua própria escrita entre regiões. O atraso de replicação significa que uma escrita em uma região pode não aparecer em outra por ~um segundo. Não escreva nos EUA e leia imediatamente da UE esperando que esteja lá; a consistência forte é de região única apenas.
• O last-writer-wins descarta dados silenciosamente. Para itens mutáveis escritos concorrentemente em duas regiões, o perdedor é descartado sem erro. Designs append-only ou de escritor-único-por-item (como este log de auditoria) evitam o problema; estado mutável compartilhado precisa de um design ciente de conflitos.
• Toda réplica custa. Cada região armazena uma cópia completa e cobra a sua própria capacidade e armazenamento — uma réplica praticamente dobra o custo. Adicione regiões para uma necessidade real de residência ou DR, não por padrão.
• Os backups são por réplica. Uma global table restaurada se torna uma tabela independente — planeje a recuperação por região. Veja backup e point-in-time recovery.

As global tables protegem contra a perda de uma região. A última preocupação operacional é proteger contra a perda de dados — um deploy ruim ou uma deleção acidental — com backup e point-in-time recovery.

Baixe o DynoTable para se conectar a múltiplas regiões e verificar que suas réplicas de global table contêm os mesmos dados.