Concurrent writes and last-write-wins

A single-leader database never has write conflicts, because one node puts every write in order. Once more than one replica accepts writes, two of them can change the same record at the same time. When they sync, something has to decide the result. The simplest decision is last-write-wins.

The big idea

Picture two people editing a shared document offline. Each one saves a new title. When they sync, the document has to show one title. Last-write-wins keeps the one with the higher timestamp and throws away the other.

The picture breaks down with clocks. The timestamp is only as honest as the clock that wrote it. A clock that runs fast wins every race, even when its write really happened first.

Walking through it

Two replicas both set the title of a document. The clocks are off, with numbers chosen for illustration.

Replica A clock: 10:00:05   writes title = "Q3 plan"       ts = 10:00:05
Replica B clock: 10:00:02   writes title = "Q3 roadmap"    ts = 10:00:02
                            (B's write is really 1 second later, but its clock is 3 s slow)

Last-write-wins keeps ts 10:00:05 -> title = "Q3 plan"
B's write is gone. No error is shown to anyone.

Last-write-wins is safe when losing a concurrent update does no harm:

• Each write has a unique key, so nothing is overwritten.
• The value is a cache entry, a "last seen" time, or a preference such as a theme.
• Conflicts are rare, and a single atomic field is fine with "one of them".

Common mistakes

• Thinking last-write-wins only drops old writes. It drops whichever write has the lower timestamp, which can be the newer one.
• Using it for money or inventory. A silently lost update is a silently lost payment.
• Trusting device clocks. Phone and laptop clocks drift. A phone set wrong can win every conflict.

Check yourself

1. Two items are added to a cart on two replicas at the same time. What does last-write-wins keep? Only one write's value. The other item disappears, and nothing reports the loss.
2. Why does a fast clock win a conflict against a later write? Last-write-wins compares timestamps, not the real order of events.

Key takeaways

• Writes are concurrent when neither replica had seen the other.
• Last-write-wins always converges, but it drops concurrent writes without an error.
• It depends on clocks, and clock drift decides the winner.
• Use it only where losing a concurrent update is harmless.

Further learning

Next, see how replicas can merge writes instead of dropping them, in CRDT counters.

Version vectors can detect concurrency exactly, without trusting clocks. See clocks and ordering.