ReplicatedWriteConflictException

In breve — Hai scritto su un Item in una global table multi-Region a coerenza forte (MRSC) mentre una richiesta in un'altra Region stava modificando lo stesso Item. La coerenza forte multi-Region non può lasciare che entrambe le vittorie atterrino, quindi una scrittura viene rifiutata. AWS la documenta come ripetibile: fai backoff e riprova, e riduci la contesa cross-Region sugli Item hot dove puoi.

Cosa significa

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

Le global table classiche (a coerenza eventuale) accettano scritture concorrenti ovunque e riconciliano in seguito con last-writer-wins. Le global table MRSC fanno il compromesso opposto: una scrittura deve essere coordinata tra le Region prima di essere confermata, quindi due Region che modificano lo stesso Item nello stesso momento sono un vero conflitto — e un lato riceve questa eccezione invece di una sovrascrittura silenziosa.

Perché accade

Lo stesso Item viene scritto da più Region contemporaneamente — due deployment applicativi che trattano entrambi l'Item come proprio da aggiornare.
Un Item di coordinamento hot — contatori, lock, o Item di configurazione singleton toccati da ogni Region sono naturali calamite per i conflitti.
Tempeste di retry tra le Region — retry simultanei della stessa operazione logica da Region diverse continuano a ricollidere.

Come correggerlo

Riprova con backoff esponenziale e jitter — il conflitto è momentaneo; una volta che la scrittura dell'altra Region si completa, il retry procede. AWS marca questo errore come ripetibile:
```
// let the SDK's adaptive retry handle it, or catch and back off:
catch (e) {
  if (e.name === 'ReplicatedWriteConflictException') return retryWithBackoff(op);
  throw e;
}
```
Dai agli Item una Region di appartenenza — instrada le scritture per una data chiave attraverso una Region (per residenza dell'utente, tenant, o partizione), mantenendo le altre Region prevalentemente in lettura. La contesa scompare quando solo una Region muta un Item.
Rendi commutativi gli aggiornamenti concorrenti — gli aggiornamenti di contatori atomici (ADD / SET x = x + :n) su attributi separati collidono meno dei cicli read-modify-write sull'intero Item.
Ri-verifica l'intento dopo aver perso la race — l'altra Region ha cambiato l'Item; un retry condizionale (ConditionExpression su un attributo di versione) assicura che la tua scrittura sia ancora valida rispetto al nuovo stato.

Osservare un Item cambiare tra le Region è molto più facile con i dati davanti a te — l'app desktop DynoTable si connette a ogni Region di replica così puoi confrontare l'Item affiancato, e il calcolatore dei prezzi DynamoDB stima quanto costano le scritture replicate.

Errori correlati

TransactionConflictException — il cugino single-Region: una transazione in corso possiede l'Item.
Global table version mismatch
ReplicaAlreadyExistsException
Impara: DynamoDB global tables

References

Ultima verifica 2026-07-13 rispetto alla documentazione ufficiale AWS collegata sopra.