ReplicatedWriteConflictException

TL;DR — Du hast in ein Item in einer regionsübergreifend stark konsistenten (MRSC) Global Table geschrieben, während ein Request in einer anderen Region dasselbe Item modifiziert hat. Starke Multi-Region-Konsistenz kann nicht beide Gewinne landen lassen, also wird ein Write abgelehnt. AWS dokumentiert ihn als wiederholbar: Warte kurz und wiederhole, und reduziere 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

1. 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;
   }

2. 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.

3. 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.

4. 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.

Verwandte Fehler

• TransactionConflictException — der Cousin innerhalb einer Region: eine laufende Transaktion besitzt das Item.
• Global table version mismatch
• ReplicaAlreadyExistsException
• Learn: DynamoDB Global Tables

Referenzen

• Error handling with DynamoDB — Amazon DynamoDB Developer Guide
• How DynamoDB global tables work — Amazon DynamoDB Developer Guide
• PutItem — Amazon DynamoDB API Reference

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