Last Writer Wins

Last writer wins is a conflict resolution rule: when two writes to the same value conflict, the one with the later timestamp is kept and the other is discarded.

It does what it promises. Because every replica applies the same rule to the same timestamps, they all reach the same answer, so the copies converge without any coordination. That is a real property and the reason the rule is so widely used as a default — Cassandra, for instance, documents a model in which every mutation is timestamped, including deletes, and the latest version becomes the winning value, applied per column.

What it does not promise is that the surviving write is the one anyone wanted. Two properties explain why.

First, the timestamps come from clocks — client or coordinator clocks, in Cassandra’s case, which is why its documentation says plainly that correctness depends on them. Where clocks disagree, the write that wins can be the one from the machine running ahead rather than the one issued later. The rule orders by clock reading, not by what actually happened.

Second, whatever loses is gone, and nothing records that a choice was made. When the discarded write was a customer’s change, nobody finds out until a repair process or a complaint surfaces it. Alternatives that keep both versions for the application to resolve trade this silence for complexity, which is a defensible trade for data where a lost update matters.

The practical test is whether losing an occasional write is acceptable for the field in question. A view counter, yes. A shipping address, probably not. How this fits with eventual consistency and clock uncertainty is worked through in Replication, Consistency, and Time.


Discover more from Insightful Data Lab

Subscribe to get the latest posts sent to your email.

Similar Posts

Questions, corrections, or additional insights?

This site uses Akismet to reduce spam. Learn how your comment data is processed.