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

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;
}
```
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.
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.
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.
Route hot coordination items through one Region. Locks, counters, and config blobs written from every Region are the usual conflict source.

Inspect in DynoTable

Compare the same item across Regions after a conflict — switch with ⌘P, open the table with ⌘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 calculator before you enable MRSC on a hot table. Configure each Region under Settings → Profiles with Test Connection. See Connect to AWS and Install.

Sources

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

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

References

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