ReplicatedWriteConflictException

TL;DR — Você escreveu em um item em uma global table multi-Region com consistência forte (MRSC) enquanto uma requisição em outra Region estava modificando o mesmo item. A consistência forte multi-Region não pode deixar ambas as vitórias aterrissarem, então uma escrita é rejeitada. A AWS a documenta como retentável: faça backoff e tente novamente, e reduza a contenção entre Regions em itens quentes onde puder.

O que significa

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

Global tables clássicas (com consistência eventual) aceitam escritas concorrentes em todo lugar e reconciliam depois com last-writer-wins. Global tables MRSC fazem a troca oposta: uma escrita precisa ser coordenada entre Regions antes de ser confirmada, então duas Regions modificando o mesmo item no mesmo momento é um conflito genuíno — e um lado recebe esta exceção em vez de uma sobrescrita silenciosa.

Por que acontece

O mesmo item é escrito de múltiplas Regions concorrentemente — dois deployments de aplicação ambos tratando o item como seu para atualizar.
Um item de coordenação quente — contadores, locks ou itens de config singleton tocados por toda Region são ímãs naturais de conflito.
Tempestades de retry entre Regions — retries simultâneos da mesma operação lógica de Regions diferentes continuam recolidindo.

Como corrigir

Tente novamente com backoff exponencial e jitter — o conflito é momentâneo; assim que a escrita da outra Region completa, o retry prossegue. A AWS marca este erro como retentável:
```
// let the SDK's adaptive retry handle it, or catch and back off:
catch (e) {
  if (e.name === 'ReplicatedWriteConflictException') return retryWithBackoff(op);
  throw e;
}
```
Dê aos itens uma Region de origem — roteie escritas para uma dada chave através de uma Region (por residência do usuário, tenant ou partição), mantendo outras Regions majoritariamente de leitura. A contenção desaparece quando apenas uma Region muta um item.
Torne atualizações concorrentes comutativas — atualizações de contador atômico (ADD / SET x = x + :n) em atributos separados conflitam menos do que ciclos de read-modify-write no item inteiro.
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.

Observar um item mudar entre Regions é muito mais fácil com os dados na sua frente — o app desktop DynoTable conecta-se a cada Region réplica para que você possa comparar o item lado a lado, e a calculadora de preços do DynamoDB estima quanto custam as escritas replicadas.

Erros relacionados

TransactionConflictException — o primo de Region única: uma transação em andamento é dona do item.
Global table version mismatch
ReplicaAlreadyExistsException
Aprenda: DynamoDB global tables

Referências

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