Given concurrent updates to one value, last-writer-wins keeps the register of whichever replica holds the largest timestamp and discards the rest: on a four-update trace worth 10 it returns 7, throwing away 2 updates worth 3. A counter CRDT keeps one component per replica, merges by elementwise maximum and sums, returning 10 and discarding none. Accurate clocks change which update survives, never how many do.
Core ideas
One rule keeps a replica, the other keeps a component per replica, and the difference is not a matter of clock quality.
The rule picks the update with the largest timestamp and takes the state of the replica that made it. That replica's register contains its own updates and nothing else, so every update made anywhere else during the partition is gone. On the trace here B holds t = 9, B's register is 3 + 4 = 7, and A's +2 and C's +1 are discarded — two updates worth three.
Make every timestamp perfectly correct and last-writer-wins still keeps one replica's register and still discards the others. All that changes is which replica is chosen. The count of discarded updates is a function of how many replicas were updated concurrently, and clock quality does not appear in it anywhere. This is the misconception the lesson exists to break.
State a counter as a vector of per-replica totals. A replica increments only its own component; merging two states takes the elementwise maximum; the value is the sum. Elementwise maximum is commutative, associative and idempotent, so every replica converges on the same value whatever order gossip arrives in, however often, and however many times a message is redelivered.
The material
What last-writer-wins does with concurrent updates, what a counter CRDT does instead, and the three properties that make the second one safe.
Updates are concurrent when no chain of messages orders them — the condition “Vector Clocks and Concurrency” makes decidable. Last-writer-wins resolves them by keeping the state of the replica holding the largest timestamp. A counter CRDT holds one count per replica, merges two states by elementwise maximum and reports the sum.
Both rules produce a single answer from conflicting states, which is what a merge has to do. The difference is what each one is willing to throw away to get there, and that is a number rather than a matter of taste.
Every one of those four updates was acknowledged to a client. Under last-writer-wins two of them stop existing at merge time, with no error raised anywhere, and the value a reader sees afterwards is 7 for a sequence of increments totalling 10. That is not a bug in the implementation; it is what the rule says to do.
The standard response to this is that the timestamps must be made accurate. Suppose they are exact to the nanosecond. The rule still keeps one replica's register and still discards every update made elsewhere; the only thing that changes is which replica gets to be the winner. What is being lost is not precision in the ordering, it is the fact that there was no ordering to be precise about — the updates were concurrent, and last-writer-wins is a rule for picking one arbitrarily.
The deeper problem is that last-writer-wins treats an increment as a state to be overwritten rather than an operation to be applied. Once +2 has become “A's register reads 2”, there is no way to combine it with “B's register reads 7” except by choosing. The counter avoids the choice by never merging the two into one slot in the first place.
Drop commutativity and the value depends on which replica gossiped first, so two replicas that exchanged the same information in opposite orders disagree for ever. Drop associativity and it depends on how the exchanges were grouped, which is a topology detail nobody controls. Drop idempotence and a redelivered message — the thing every network does under retry — double counts. Elementwise maximum has all three, which is why the convergence needs no coordination at all: no ordering, no exactly-once delivery, no leader.
A grow-only counter is the easy case and it should be read as an existence proof rather than a general solution. Sets with removals, registers holding documents, and ordered sequences all need more machinery, and some conflicts are genuinely business decisions that no merge rule should be making. What transfers is the question: for this data type, what does my merge rule discard, and can I count it?
Interactive
What last-writer-wins throws away, and what a counter CRDT keeps
Method
The trace first, the concurrency second, and only then the merge — because a rule applied to updates that were not concurrent discards nothing and proves nothing.
One line per acknowledged update. If the updates are increments, keep them as increments rather than as the resulting values — the distinction between an operation and a state is where the whole difference lives.
Use the vector-clock comparison: if one update's vector dominates another's, they are ordered and there is no conflict to resolve. A merge rule is only tested by the pairs that are genuinely incomparable.
Find the largest timestamp, take that replica's state, and count the updates that are not in it and the value they carried. Report both: “two updates, worth three” says more than either half alone.
For a counter, elementwise maximum then sum, compared with the sum of all the increments. If they agree, the rule discards nothing; if they do not, the difference is what it discards and you now know its size.
Three replicas are partitioned from one another and each accepts writes. Four increments are acknowledged during the partition. The partition heals, the replicas gossip, and the question is what the counter reads afterwards — under each of the two rules on offer.
Seven against ten, for a rule that raises no error and is the default in a great deal of software. The thirty per cent is not an edge case either — it is what happens whenever three replicas take writes and two of them are not the one holding the largest timestamp.
The last block is the one to argue with somebody about. Improving the clocks is the reflex fix and it changes the identity of the survivor without changing the arithmetic: two updates are still discarded, because two replicas other than the winner accepted writes. Clock accuracy is the answer to a question about ordering, and these updates were not ordered.
For a faded rehearsal, add a fifth update A:11:+5 to the trace. The supplied first move is that the largest timestamp is now 11 and it is held by A, so A's register wins. Work out the new last-writer-wins value, the number and worth of the updates it discards, and the CRDT's value — then say, before checking in the lab, whether the number discarded went up or down and why.
You should be able to establish that a set of updates is concurrent, compute the last-writer-wins value together with the number and worth of what it drops, compute a counter CRDT's value from its components, state the three merge laws and what each one buys, and say why clock accuracy does not change the count.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.