ReplicatedWriteConflictException

TL;DR — You wrote to an item in a multi-Region strongly consistent (MRSC) global table while a request in another Region was modifying the same item. Strong multi-Region consistency can't let both wins land, so one write is rejected. AWS documents it as retryable: back off and retry, and reduce cross-Region contention on hot items where you can.

What it means

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

Classic (eventually consistent) global tables accept concurrent writes everywhere and reconcile afterwards with last-writer-wins. MRSC global tables make the opposite trade: a write must be coordinated across Regions before it's acknowledged, so two Regions modifying the same item at the same moment is a genuine conflict — and one side gets this exception instead of a silent overwrite.

Why it happens

• The same item is written from multiple Regions concurrently — two application deployments both treating the item as theirs to update.
• A hot coordination item — counters, locks, or singleton config items touched by every Region are natural conflict magnets.
• Retry storms across Regions — simultaneous retries of the same logical operation from different Regions keep re-colliding.

How to fix it

1. Retry with exponential backoff and jitter — the conflict is momentary; once the other Region's write completes, the retry proceeds. AWS marks this error retryable:

   // 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. Give items a home Region — route writes for a given key through one Region (by user residency, tenant, or partition), keeping other Regions read-mostly. Contention disappears when only one Region mutates an item.

3. Make concurrent updates commutative — atomic counter updates (ADD / SET x = x + :n) on separate attributes conflict less than read-modify-write cycles on the whole item.

4. Re-check intent after losing the race — the other Region changed the item; a conditional retry (ConditionExpression on a version attribute) ensures your write is still valid against the new state.

Watching an item change across Regions is much easier with the data in front of you — the DynoTable desktop app connects to each replica Region so you can compare the item side by side, and the DynamoDB pricing calculator estimates what replicated writes cost.

Related errors

• TransactionConflictException — the single-Region cousin: an ongoing transaction owns the item.
• Global table version mismatch
• ReplicaAlreadyExistsException
• Learn: DynamoDB global tables

References

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

Last verified 2026-07-13 against the official AWS documentation linked above.