In an eventually consistent data store, two replicas each accept a write to the same key while a network partition separates them. When the partition heals and the store uses last-write-wins (LWW) to reconcile, what happens to the value, and what has to happen for that to work reliably?

## How LWW picks a winner Last-write-wins (**LWW**) is the simplest conflict-resolution strategy an eventually consistent store can use: when two replicas hold different values for the same key because they each accepted a write while the other was unreachable, the store compares a timestamp attached to each write and keeps the value with the larger timestamp, discarding the other entirely. The timestamp is usually written client-side or coordinator-side at write time — either: - a raw **wall-clock reading**, - or increasingly a **hybrid logical clock (HLC)** that combines a physical clock with a logical counter so that ties and small clock skew can be broken deterministically. Some systems also carry a replica or node id as a final tie-breaker when timestamps are exactly equal, so the outcome is deterministic no matter which replica performs the comparison. Once the partition heals and replicas exchange their versions (via anti-entropy, read-repair, or hinted handoff), each replica runs the same comparison and converges on the same winner — that determinism is what makes LWW usable in a leaderless, multi-master system with no coordinator to arbitrate. ## Why it exists LWW exists because most other conflict-resolution techniques require either: - a **central authority** to serialize writes (which sacrifices availability during partitions, the thing eventual consistency is trying to preserve), - or **application code** that understands how to merge two divergent values (extra engineering work the application team may not want to do for every field). LWW sidesteps both: it needs no consensus round and no domain-specific merge function, just a comparable timestamp already present on the write. That makes it the default conflict policy in systems like **Cassandra** (per-cell timestamps) and **Riak** (as one of several selectable policies), and it's attractive whenever the 'right' answer really is 'whichever write happened most recently,' such as a user's last-known IP address or a cache entry. ## The trade-off The trade-off is that LWW buys simplicity by being willing to lose data. The losing write isn't merged, queued for review, or even logged by default — it simply vanishes, and neither client that made the concurrent writes is told anything happened. This is acceptable for values where only the latest state matters, but it is the wrong tool whenever a write represents an operation rather than a value replacement — two concurrent 'add item to cart' writes are not readings of the same underlying fact, and picking one over the other silently drops a customer's item. ## Failure modes 1. **Clock-skew-induced causality violation** — the dominant failure mode. Because LWW orders writes by timestamp rather than by actual happened-before relationships, a write that is causally later (a client saw the first write's result and then issued a follow-up) can still lose if its node's physical clock lags behind the other node's. A concrete pattern that shows this in production: a user updates their profile, the update briefly appears, then an older cached write from a lagging replica 'wins' during reconciliation and the user's change disappears — without any error being raised, which makes it a support-ticket generator rather than something caught in testing. 2. **Timestamp granularity** — a second failure mode. Many implementations timestamp whole values or whole rows rather than individual fields, so an update to field A on one replica can wholly overwrite a concurrent update to field B on another replica, even though the two changes don't logically conflict at all. ## Cassandra in practice A well-known real-world instance is Cassandra's default conflict resolution: every column (cell) write carries a client-supplied or server-assigned microsecond timestamp, and on read (or during compaction/repair) the cell with the highest timestamp wins per-column. This per-column granularity mitigates the whole-row-clobber problem somewhat, but Cassandra explicitly warns operators to keep NTP-synchronized clocks tight, because two writes issued within the same clock-skew window can resolve in the 'wrong' order relative to what actually happened. Teams that need correctness guarantees stronger than 'usually right, occasionally silently wrong' either: - pair LWW with hybrid logical clocks to shrink the skew window, - or move the field to a strategy that preserves both writes (vector clocks plus application merge) instead of discarding one.