Run a Lamport clock and a vector clock over the same ten-event log. Two events come out L(e9) = 3 < 4 = L(e4) — begging the reading “e9 happened before e4” — but they were concurrent: no message path connects them, and the vectors [0,0,3] and [2,2,0] are incomparable. Then drop Lamport’s max-on-receive rule and even its one guarantee breaks: a message sent at timestamp 2 is received at timestamp 1, so the effect looks earlier than its cause.
A Lamport timestamp is one integer per event (plus a node id to break ties). It buys a total order, and that order is safe in exactly one direction: if a happened-before b, then L(a) < L(b). The reverse is a trap. Run a Lamport clock and a vector clock over the same event log and you find a pair of events e9 and e4 with L(e9) = 3 < 4 = L(e4) — which begs the reader to conclude “e9 happened before e4” — that were in fact concurrent: no message path connects them, neither causally precedes the other. The vector clock stamps them [0,0,3] and [2,2,0], neither dominates the other, and reports concurrent. Then watch the mechanism: strip Lamport’s max-on-receive rule and even the one-way guarantee collapses — a message received at e3 gets timestamp 1 though it was sent at e2 with timestamp 2, so the effect now looks earlier than its cause.
This exercise is the counterpart to Ch. 6’s version-vectors, which uses per-process counters to detect conflicting sibling writes. There the angle was conflict detection; here it is the total-order illusion — a single integer that reads like causality but isn’t — and the max-on-receive mechanism that a Lamport clock rests on.
Designing Data-Intensive Applications, 2nd ed. (Kleppmann & Riccomini, 2025), Chapter 10 — Consistency and Consensus, §"Lamport timestamps / hybrid logical clocks versus vector clocks."
Lamport timestamps give a total order consistent with causality —a → bimpliesL(a) < L(b)— but from a Lamport timestamp alone you cannot tell whether two events are concurrent or causally ordered; only a vector clock (one entry per node) distinguishes the two.
Here you build both over one log and watch exactly that gap open.
The surprise turns on a one-directional implication. Each line notes where the idea shows up in the run.
a → b ("a happened-before b") holds if a is earlier on the same process, or a is a send and b its receive, or by transitivity. Two events are concurrent when neither a → b nor b → a. It shows up as e9 and e4: no chain of process-steps or messages links them. Concurrency is about the absence of a causal path, not wall-clock simultaneity. (carries the result)L = max(local, message) + 1. It totally orders all events and guarantees a → b ⇒ L(a) < L(b). It shows up as the Lamport column. The one-way part is the whole trap. (carries the result)V(a) ≤ V(b) componentwise iff a → b, so incomparable vectors mean concurrent. It shows up as the vector [P1,P2,P3] column and the dominates check.a → b ⇒ L(a) < L(b) is true; its converse L(a) < L(b) ⇒ a → b is false. It shows up as L(e9) < L(e4) on concurrent events. (carries the result)Both clocks watch the same ten events; only the stamp differs.
a → b ⇒ L(a) < L(b)) but says nothing about events that aren’t related. Two concurrent events still get two different numbers, and the smaller one is not "earlier" in any causal sense — it just lost the tie. The integer has one slot; it cannot record which process knew what, only a running high-water mark.V(a) ≤ V(b) in every component means everything a knew, b knew too → a → b. If each vector has a component the other lacks, neither knew the other → concurrent. Domination = causality; incomparability = concurrency.The event log (three processes, two messages):
P1: e1 local --- e2 send(m1) ---------------------------------.
\ |
P2: e3 recv(m1) - e4 local - e5 local - e6 send(m2)
\
P3: e7 local - e8 local - e9 local ----------------------- e10 recv(m2)There is no message path from P3’s local run (e7, e8, e9) to P2’s local run (e4, e5) — those events are genuinely concurrent. Everything is one script, code/lamport_vs_vector_clocks.py.
cd study/ddia/ch10
python3 code/lamport_vs_vector_clocks.pyDo not read the output yet — make each prediction first.
Predict. Walk the log with both rules. Lamport: local/send do L += 1; recv does L = max(local, message) + 1. Vector: bump your own component, and on receive take the componentwise max first. P3 does three local events (e7, e8, e9) before receiving m2. What Lamport timestamp does e9 get? What vector?
e9 is P3’s third local event, so it climbs P3’s own counter to Lamport 3 and vector [0,0,3] — a stamp that knows nothing of P1 or P2. e4 sits on P2 at Lamport 4, vector [2,2,0] — it has already absorbed m1 from P1.
Predict. Compare e9 (Lamport 3) and e4 (Lamport 4). Lamport says 3 < 4. Is e9 actually happened-before e4? Check the vectors: does either [0,0,3] or [2,2,0] dominate the other componentwise?
L(e9) < L(e4) is real, but it does not mean e9 → e4. e9 knows P3 did 3 steps ([_,_,3]) and nothing of P2; e4 knows P2 did 2 steps and saw P1 ([2,2,_]) and nothing of P3. Each vector has a component the other lacks → neither happened-before the other → concurrent. Lamport’s 3 < 4 is a tie-break, not a causal fact.
Predict. Now take e2 (send m1) and e3 (receive m1). A send always happens-before its receive, so this pair is causal. Will Lamport order them the same way, and will the vector for e3 dominate the vector for e2?
When the pair really is causal, both agree — L(e2) < L(e3) and [2,1,0] dominates [2,0,0]. That is the one-way guarantee working: a → b ⇒ L(a) < L(b). The trap in Step 2 was the converse, L(a) < L(b) ⇒ a → b, which is false.
Predict. Recompute Lamport with the receive rule changed to a plain L += 1 — the receiver ignores the message’s timestamp. Message m1 is sent at e2 (Lamport 2) and delivered to e3, which is P2’s first event. Without max-on-receive, what timestamp does e3 get — and is L(e2) < L(e3) still true?
Without max-on-receive, P2’s counter knows only its own history — one step — so e3 gets 1, though the message it delivered was sent at 2. Now L(e2) = 2 > 1 = L(e3): the receive is stamped below its send, so the effect reads as earlier than its cause. max(local, message) + 1 is the minimum fix — it forces the receiver past the message’s timestamp — and e3 becomes 3 > 2.
e9 = Lamport 3 / [0,0,3], e4 = Lamport 4 / [2,2,0].L(e9) = 3 < 4 = L(e4), yet the vectors are incomparable — the pair is concurrent, so "e9 before e4" is false.e2 → e3 (send/recv of m1) — Lamport 2 < 3 and [2,1,0] dominates [2,0,0]; both agree.m1’s receive e3 is stamped 1 below its send e2 at 2 — the one-way guarantee violated. The MAX rule restores e3 = 3 > 2.Start from the guarantee Lamport actually gives. Every event advances a counter, and a receive takes max(local, message) + 1, so any event on the causal path from a to b — same-process successors, and receives of a’s messages — is forced strictly higher than a. By transitivity a → b ⇒ L(a) < L(b). That is real and it is all Lamport promises.
The converse fails because the guarantee is a projection that throws away information. A single integer is a high-water mark: it records the length of the longest causal chain leading to this event, and nothing about which processes contributed to that chain. e9’s counter reached 3 purely from P3’s own local steps; e4’s reached 4 from P2’s steps plus the m1 it absorbed from P1. Two different chains, two different lengths — and 3 < 4 compares the lengths, not the causality. When two events lie on unrelated chains (no message ever flowed between their branches), Lamport still hands back two numbers, and one is smaller. The order is consistent with causality (it never contradicts a real a → b) but not faithful to it (it invents an order where none exists).
A vector clock keeps exactly the discarded piece: one component per process, so the stamp says how much of each process’s history this event has seen. a → b holds iff b has seen at least as much of every process as a — i.e. V(a) ≤ V(b) in all components. Concurrency is then visible directly: if a has seen more of some process than b, and b more of another, then a causal path cannot exist in either direction (a path would have carried the counts along), so the vectors are incomparable and the events are concurrent. That is why the vector can detect the absence of a causal path and the integer cannot — the integer summed the per-process knowledge into one number and lost the ability to ask "did b know everything a knew?"
The mechanism demo isolates why max-on-receive is not optional. The only way a send can influence the receiver’s counter is for the receive to read the message’s timestamp; a bare L += 1 leaves the receiver advancing on its own local history alone. If that history is shorter than the sender’s — and P2’s first event has history length 0 — the receive lands below the send, and the lone guarantee a → b ⇒ L(a) < L(b) is gone. max(local, message) is the minimum coupling: it pulls the receiver up to at least the message’s height before the +1, so no receive can ever undercut its send.
L(a) < L(b) back as "a caused b." Reach for a vector clock the moment the question is "were these concurrent?" — sibling detection, conflict resolution, causal consistency — and for a plain Lamport clock when the question is only "give me one order we all share."
neither dominates) is the identical rule that flags [milk] and [eggs] as concurrent there — one mechanism, two uses (ordering vs conflict detection).Sources: DDIA 2e, Ch. 10, §"Lamport timestamps / hybrid logical clocks versus vector clocks" · Lamport, "Time, Clocks, and the Ordering of Events in a Distributed System" (1978) · Fidge (1988), Mattern (1988) on vector clocks.