Last-write-wins is popular because it's simple and requires no application involvement. Walk through at least three concrete ways LWW can silently lose committed data or violate causality in production, and describe one situation where you would deliberately choose LWW anyway despite these risks.

## What the single comparison discards Last-write-wins collapses conflict resolution to a single comparison — pick the write with the larger timestamp — which is attractive because it requires no extra metadata beyond a clock reading and no application involvement, but that same simplicity is exactly what causes its failure modes: it discards the causal information that would let the system tell the difference between 'this write is genuinely newer' and 'this write merely has a larger number attached to it.' ## Three failure modes 1. **Clock-skew-induced causality violation** — the first and most cited failure mode. If node A's physical clock runs ahead of node B's, a write accepted by A can carry a timestamp later than a write accepted by B even when B's write causally happened after A's — for instance, a client reads A's write and then deliberately issues a follow-up write to B a second later in real time, yet A's skewed clock still stamps its (earlier) write with a larger number. LWW then keeps A's stale write and discards B's intentional follow-up, and nothing in the system flags this as wrong: it's a valid-looking write with a valid-looking timestamp, just the wrong one. This is why systems that rely on LWW invest heavily in tight clock synchronization (NTP, physical time devices like Spanner's TrueTime, or hybrid logical clocks that bound the skew window), because the correctness of LWW degrades directly with how much clocks can disagree. 2. **Granularity** — the second failure mode. Many LWW implementations compare and swap an entire value — a whole row, a whole document — rather than individual fields, because tracking timestamps at finer granularity costs more metadata. When two clients concurrently modify different fields of the same record starting from the same base version, whole-value LWW keeps one client's entire document and discards the other's entirely, even though the two changes didn't logically conflict at all — a user changing their bio and, seconds later on a different device, changing their avatar can end up with only one of the two changes surviving, purely because of write ordering unrelated to the actual conflict. Cassandra mitigates this specifically by timestamping at the column (cell) level rather than the row level, which narrows but doesn't eliminate the problem — a delete-then-recreate of a whole row, or a batch of column writes issued together, can still exhibit whole-value-like clobbering. 3. **The delete/update race** — the third failure mode, and often the most operationally painful. Because a delete is just another write competing on the same timestamp axis, a concurrent update and delete of the same key resolve however their timestamps happen to compare, with no special-casing for the fact that 'deleted' is a different kind of state than 'has a value.' If the delete's timestamp is later, the record correctly disappears; if a stale update happens to carry a later timestamp than the delete (which can happen with clock skew, or with delayed message delivery through a queue), the deleted record can silently reappear — a 'zombie' write — well after the user thought it was gone. This is one of the reasons deletes in LWW-based systems are usually implemented as tombstones with their own retention and compaction rules rather than as physical removal, precisely so a late-arriving update can still be compared against and correctly lose to a tombstone within its retention window. ## Why the damage stays invisible None of these three failure modes produce an error the application can catch — they all manifest as a quietly different final state, discovered later (if ever) as a confused support ticket, a re-appearing deleted item, or a change that 'didn't stick.' ## When LWW is still the right choice That said, LWW remains the right engineering choice for a large class of data precisely because these failure modes are tolerable there: - **session heartbeats and presence/'last seen' fields** only ever care about the freshest value, so losing a stale concurrent write is definitionally correct behavior, not a bug; - **high-volume metrics or cache entries** can tolerate an occasional lost sample without changing any aggregate a human relies on; - **the operational simplicity** — no per-key metadata growth, no sibling management, no merge functions to write and test — is a real, ongoing cost saving at scale. The engineering judgment call is asking, for each field, 'if this write silently disappears with no error and no notification, does anyone's outcome change?' — if the answer is no, LWW is the pragmatic default; if the answer is yes (money, inventory, user-authored content, anything representing an operation rather than a value snapshot), it's the wrong tool and the cost of vector clocks plus a merge function, or a CRDT, is money well spent.