Conflict Resolution
Merge concurrent updates using semantics that preserve the product's invariants.
2–5 minute refresher
Detect concurrency → preserve intent → merge or escalate by business rule
30second
refresher
refresher
Concurrent writes occur when replicas accept updates without one shared order. Resolution may reject one write, select a winner, merge fields, use a convergent data type, or ask a human—depending on the invariant.
What problem does it solve?
Multi-writer and offline systems can create valid updates from the same earlier version. Replicas need deterministic convergence without silently destroying important intent.
How it works
- Attach version metadata that can identify stale and concurrent writes.
- Classify the data by invariant and mergeability.
- Choose rejection, deterministic winner, semantic merge, CRDT, or manual resolution.
- Apply the rule identically at every replica.
- Retain conflict evidence and measure how often resolution loses or escalates intent.
Decision guide
Key trade-offs
| Choice | What you gain | What it costs |
|---|---|---|
| Last-write-wins | Simple bounded state | Silent intent loss and clock assumptions |
| Sibling versions | Preserve concurrent intent | Read-time complexity |
| CRDT | Automatic convergence | Restricted data semantics and metadata |
What happens if?
Two regions decrement the last inventory item
A generic merge can oversell because the invariant is non-commutative. Route the scarce resource through one authority, escrow bounded rights per region, or reject and reconcile explicitly.
Where it appears
- Dynamo sibling versions
- Cassandra timestamps
- Collaborative editors
- CRDT-based stores
Senior interview modeWhen is a CRDT a good fit for conflict resolution?Show answer
When the data type's operations can be modeled with associative, commutative, and idempotent merge semantics that preserve the actual product invariant, such as sets or counters with well-defined behavior.