Last Write Wins Conflicts
When two replicas accept concurrent writes to the same key, they must merge to one value. Last write wins is the simplest rule. Each write carries a timestamp, and the value with the larger timestamp is kept while the other is discarded.
It is attractive because it is trivial to implement and always produces a single deterministic answer. Both replicas, given the same two writes, pick the same winner, so they converge.
The danger is silent data loss. If two clients write at nearly the same moment, last write wins keeps one and throws the other away, even though both were legitimate. The discarded write simply vanishes, with no error and no merge. For a shopping cart this could delete an item a user added.
There is a deeper problem. Timestamps come from clocks, and clocks drift between machines. A write that happened later in real time may carry an earlier timestamp because its server clock was behind. Then the older write incorrectly wins, and causality is violated.
- Deterministic Both replicas pick the same winner, so they converge.
- Lossy Concurrent writes silently discard the loser.
- Clock dependent Skewed clocks can let an earlier write beat a later one.
Use last write wins only when losing a concurrent update is acceptable, or pair it with logical clocks to respect causality.
Key idea
Last write wins resolves conflicts by keeping the highest timestamped value, which is simple and convergent but silently drops concurrent writes and can misorder events when clocks drift.