ReplicatedWriteConflictException

TL;DR — Du hast in einer Multi-Region-Strongly-Consistent-Global-Table (MRSC) auf ein Item geschrieben, während ein Request in einer anderen Region dasselbe Item geändert hat. Starke Multi-Region-Konsistenz kann nicht beide Writes gewinnen lassen, also wird einer abgelehnt. AWS dokumentiert das als wiederholbar: Backoff und Retry, und reduzier regionsübergreifende Konkurrenz auf heißen Items, wo du kannst.

Was es bedeutet

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

Klassische (letztendlich konsistente) Global Tables akzeptieren gleichzeitige Writes überall und gleichen sie hinterher per Last-Writer-Wins ab. MRSC Global Tables treffen den umgekehrten Kompromiss: Ein Write muss über Regionen hinweg koordiniert werden, bevor er bestätigt wird, sodass zwei Regionen, die dasselbe Item im selben Moment modifizieren, ein echter Konflikt sind — und eine Seite bekommt diese Exception statt eines stillen Überschreibens.

Warum es passiert

Dasselbe Item wird gleichzeitig aus mehreren Regionen geschrieben — zwei Anwendungsbereitstellungen, die das Item beide als ihres zum Aktualisieren behandeln.
Ein heißes Koordinations-Item — Zähler, Locks oder Singleton-Config-Items, die von jeder Region berührt werden, sind natürliche Konfliktmagnete.
Retry-Stürme über Regionen hinweg — gleichzeitige Retries derselben logischen Operation aus verschiedenen Regionen kollidieren immer wieder neu.

So behebst du es

Wiederhole mit exponentiellem Backoff und Jitter — der Konflikt ist momentan; sobald der Write der anderen Region abgeschlossen ist, geht der Retry durch. AWS markiert diesen Fehler als wiederholbar:
```
// let the SDK's adaptive retry handle it, or catch and back off:
catch (e) {
  if (e.name === 'ReplicatedWriteConflictException') return retryWithBackoff(op);
  throw e;
}
```
Gib Items eine Heimatregion — leite Writes für einen bestimmten Schlüssel über eine Region (nach Nutzer-Residenz, Mandant oder Partition) und halte andere Regionen überwiegend lesend. Konkurrenz verschwindet, wenn nur eine Region ein Item mutiert.
Mache gleichzeitige Updates kommutativ — atomare Zähler-Updates (ADD / SET x = x + :n) auf separaten Attributen kollidieren weniger als Read-Modify-Write-Zyklen auf dem gesamten Item.
Prüfe die Absicht erneut, nachdem du das Rennen verloren hast — die andere Region hat das Item geändert; ein bedingter Retry (ConditionExpression auf einem Versionsattribut) stellt sicher, dass dein Write gegen den neuen Zustand noch gültig ist.

Ein Item über Regionen hinweg zu beobachten, wie es sich ändert, ist mit den Daten vor Augen viel einfacher — die DynoTable-Desktop-App verbindet sich mit jeder Replica-Region, sodass du das Item nebeneinander vergleichen kannst, und der DynamoDB-Preisrechner schätzt, was replizierte Writes kosten.

In DynoTable prüfen

Compare the same item across Regions nachdem a conflict — switch with ⌘P, öffne die Tabelle mit ⌘K, and read the item in each replica Region side by side. Staging (⌘S) lets you prepare a conditional retry and review the diff before commit.

Estimate replicated write cost with the Pricing-Rechner bevor du enable MRSC on a hot table. Configure each Region under Einstellungen → Profile with Verbindung testen. Siehe Mit AWS verbinden und Installation.

Quellen

How DynamoDB global tables work (verifiziert 2026-07-13)
Error handling with DynamoDB (verifiziert 2026-07-13)

Referenzen

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.