DynoTable

ReplicatedWriteConflictException

TL;DR — Você escreveu em um item em uma tabela global multi-região fortemente consistente (MRSC) enquanto uma solicitação em outra região estava modificando o mesmo item. A forte consistência multirregional não permite que ambas as vitórias aconteçam, então uma gravação é rejeitada. O AWS documenta isso como passível de nova tentativa: faça backoff e tente novamente, e reduza a contenção entre regiões em itens importantes sempre que possível.

O que significa

ReplicatedWriteConflictException: One or more items in this request are
being modified by a request in another Region.

As tabelas globais clássicas (eventualmente consistentes) aceitam escritas simultâneas em todos os lugares e depois se reconciliam com as vitórias do último escritor. As tabelas globais do MRSC fazem o oposto: uma gravação deve ser coordenada entre as regiões antes de ser reconhecida, portanto, duas regiões modificando o mesmo item ao mesmo tempo é um conflito genuíno - e um lado recebe esta exceção em vez de uma substituição silenciosa.

Por que isso acontece

  • O mesmo item é gravado em várias regiões simultaneamente — duas implantações de aplicativos tratando o item como se fossem suas para atualização.
  • Um item de coordenação quente — contadores, bloqueios ou itens de configuração singleton tocados por cada região são ímãs naturais de conflito.
  • Repetidas tempestades entre regiões — novas tentativas simultâneas da mesma operação lógica de regiões diferentes continuam colidindo novamente.

Como corrigir

  1. Tentar novamente com espera exponencial e jitter — o conflito é momentâneo; assim que a gravação da outra região for concluída, a nova tentativa continuará. A AWS marca este erro como passível de nova tentativa:

    // let the SDK's adaptive retry handle it, or catch and back off:
catch (e) {
  if (e.name === 'ReplicatedWriteConflictException') return retryWithBackoff(op);
  throw e;
}

  2. Dê a cada item uma região de origem — encaminhe as gravações de uma dada chave por uma única região (por residência do usuário, tenant ou partição), mantendo as outras regiões majoritariamente de leitura. A contenção some quando só uma região altera um item.

  3. Torne as atualizações concorrentes comutativas — atualizações de contador atômico (ADD / SET x = x + :n) em atributos separados conflitam menos do que ciclos de leitura-modificação-escrita no item inteiro.

  4. Reverifique a intenção após perder a corrida — a outra Region mudou o item; um retry condicional (ConditionExpression em um atributo de versão) garante que sua escrita ainda é válida contra o novo estado.

  5. Roteie itens de coordenação quentes por uma única Region. Locks, contadores e blobs de configuração escritos a partir de toda Region são a fonte usual de conflito.

Inspecione no DynoTable

Compare o mesmo item entre Regions depois de um conflito — troque com ⌘P, abra a tabela com ⌘K e leia o item em cada Region réplica lado a lado. O staging (⌘S) permite preparar um retry condicional e revisar o diff antes do commit.

Estime o custo das escritas replicadas com a calculadora de preços antes de habilitar MRSC em uma tabela quente. Configure cada Region em Settings → Profiles com Test Connection. Veja Connect to AWS e Install.

Fontes

Erros relacionados

Referências

Verificado pela última vez em 2026-07-13 contra a documentação oficial da AWS vinculada acima.

Trabalhe com o DynamoDB sem o Console

Um cliente desktop rápido para DynamoDB que roda o SQL de verdade que o DynamoDB não consegue — JOINs, GROUP BY, agregações — com edição visual e um agente de IA com suas próprias chaves do Bedrock.

BaixarVer preços

Teste grátis de 30 dias, sem cartão de crédito — depois o plano Grátis sem limite de tempo.