ReplicatedWriteConflittiException

TL;DR: hai scritto su un elemento in una tabella globale fortemente coerente con più regioni (MRSC) mentre una richiesta in un'altra regione stava modificando lo stesso elemento. Una forte coerenza multi-regione non può consentire di ottenere entrambe le vittorie, quindi una scrittura viene rifiutata. AWS lo documenta come riprovabile: fai marcia indietro e riprova e riduci il conflitto tra regioni sugli elementi importanti dove puoi.

Cosa significa

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

Le tabelle globali classiche (eventualmente coerenti) accettano scritture simultanee ovunque e si riconciliano successivamente con le vittorie dell'ultimo scrittore. Le tabelle globali MRSC fanno il commercio opposto: una scrittura deve essere coordinata tra le regioni prima di essere riconosciuta, quindi due regioni che modificano lo stesso elemento nello stesso momento costituiscono un vero conflitto e una parte ottiene questa eccezione invece di una sovrascrittura silenziosa.

Perché succede

Lo stesso elemento viene scritto da più regioni contemporaneamente: due distribuzioni dell'applicazione trattano entrambe l'elemento come se fosse loro da aggiornare.
Un elemento di coordinazione importante: contatori, lucchetti o elementi di configurazione singleton toccati da ogni regione sono calamite naturali per i conflitti.
Tentativi di tentativi tra regioni: i tentativi simultanei della stessa operazione logica da regioni diverse continuano a collidere.

Come risolverlo

Riprova con backoff e jitter esponenziali: il conflitto è momentaneo; una volta completata la scrittura dell'altra regione, il nuovo tentativo procede. AWS contrassegna questo errore come riprovabile:
```
// let the SDK's adaptive retry handle it, or catch and back off:
catch (e) {
  if (e.name === 'ReplicatedWriteConflictException') return retryWithBackoff(op);
  throw e;
}
```
Assegna agli elementi una regione home: instrada le scritture per una determinata chiave attraverso una regione (per residenza dell'utente, tenant o partizione), mantenendo le altre regioni per lo più in lettura. La contesa scompare quando solo una regione modifica un oggetto.
Rendi commutativi gli aggiornamenti simultanei — gli aggiornamenti dei contatori atomici (ADD / SET x = x + :n) su attributi separati entrano in conflitto meno dei cicli di lettura-modifica-scrittura sull'intero elemento.
Ricontrolla l'intento dopo aver perso la gara: l'altra regione ha cambiato l'elemento; un nuovo tentativo condizionale ("ConditionExpression" su un attributo di versione) garantisce che la tua scrittura sia ancora valida rispetto al nuovo stato.
Instradare gli elementi di coordinamento attivo attraverso una regione. Blocchi, contatori e BLOB di configurazione scritti da ogni regione sono la consueta fonte di conflitto.

Ispeziona in DynoTable

Confronta lo stesso elemento tra le regioni dopo un conflitto: cambia con ⌘P, apri la tabella con ⌘K e leggi l'elemento in ciascuna regione replicata fianco a fianco. La gestione temporanea (⌘S) ti consente di preparare un nuovo tentativo condizionale e rivedere la differenza prima del commit.

Stimare il costo di scrittura replicato con il calcolatore dei prezzi prima di abilitare MRSC su una hot table. Configura ciascuna regione in Impostazioni → Profili con Connessione di prova. Consulta Connetti a AWS e Installa.

Fonti

Come funzionano le tabelle globali DynamoDB (verificato il 13-07-2026)
Gestione degli errori con DynamoDB (verificato il 2026-07-13)

Errori correlati

TransactionConflittiException — il cugino a regione singola: una transazione in corso possiede l'oggetto.
Mancata corrispondenza della versione globale della tabella
ReplicaAlreadyExistsException
Impara: DynamoDB tabelle globali

Riferimenti

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