cd ../blog

Vector Clocks Without the Hand-Waving

Happens-before, concurrency, and conflict detection explained with a worked example instead of a wall of subscripts.

Vector clocks get taught as a wall of subscripts, which is a shame, because the idea is simple: give every node a counter, ship the whole vector with each message, and you can tell — precisely — whether one event happened before another or the two are genuinely concurrent.

# the two rules

Each node keeps a vector of counters, one slot per node. On a local event, a node bumps its own slot. On receiving a message, it takes the element-wise max of its vector and the sender's, then bumps its own slot again. That's the entire algorithm.

To compare two events, compare their vectors element by element. If every entry of A is ≤ B (and they differ), A happened-before B. If neither dominates the other, the events are concurrent — and concurrency is exactly the signal you need to detect a write conflict.

A vector clock doesn't resolve conflicts. It tells you, without guessing, that a conflict exists.

# where it pays off

Dynamo-style stores use this to keep sibling versions instead of silently overwriting. When two vectors are concurrent, the system hands both values back to the application and lets it merge them. No wall clock, no lost writes, no pretending time is a total order when it isn't.