Overview
When two replicas accept concurrent writes to the same key, a system must reconcile them. Last-Write-Wins picks a single winner by timestamp and discards the rest, while Merging combines both writes into a new value using domain-specific or CRDT logic.
Comparison Diagram
Comparison Table
| Aspect | Last-Write-Wins | Merging |
|---|---|---|
| Conflict trigger | Fires when two writes to the same key arrive with overlapping validity, regardless of content | Fires the same way, but treats both writes as valid inputs rather than competitors |
| Resolution mechanism | Compares timestamps (or version numbers) and keeps the highest one | Applies a merge function, CRDT join, or three-way diff to combine both values |
| Data/metadata required | A reliable clock or monotonic counter per write | Version vectors, causal history, or a semantically defined merge operation |
| Application involvement | None — resolution is automatic and content-agnostic | Requires the app or data structure to define what ‘combining’ means |
| Outcome for the losing write | Discarded entirely, no trace remains | Incorporated into the final merged state, nothing is dropped |
| Consistency guarantee | Deterministic convergence, but the winner may be arbitrary relative to causality | Deterministic convergence that also respects the semantics of both updates |
| Performance overhead | Minimal — a single comparison per conflict | Higher — merge logic, extra metadata, and sometimes multi-way comparisons |
| Failure mode | Silent data loss under clock skew or concurrent writes at the same timestamp | Unresolvable merge conflicts that surface to the application or user |
Key Differences
- LWW resolves conflicts purely by comparing timestamps, keeping only one write.
- Merging combines concurrent writes using a merge function or CRDT join instead of picking a single winner.
- LWW can cause silent data loss when clocks skew or writes race within the same tick.
- Merging needs semantic knowledge of the data type to combine values correctly.
- LWW adds negligible overhead per write; merging trades that simplicity for correctness under concurrency.
When to Use Each
Last-Write-Wins
- Cache and Session State: Losing a stale write is harmless when the data is ephemeral and quickly overwritten again.
- High-throughput Key-Value Stores: The cost of per-write merge logic isn’t worth it when most keys never actually conflict.
- Simple Last-Update Semantics: When the business rule genuinely is ‘most recent value wins’, LWW implements it directly with no extra logic.
Merging
- Collaborative Document Editing: Concurrent edits from multiple users must all be preserved, not overwritten by whichever arrives last.
- Shopping Cart Synchronization: Items added on different devices while offline need to be unioned together, not have one device’s additions dropped.
- Distributed Counters and Sets: CRDT-based merges let increments or set additions from every replica accumulate correctly on reconciliation.