Qingwa town had three apothecary shops — Renhe Hall on East Street, Jishi Workshop in South Lane, and Tongchun House on West Slope. Each had its own herb cabinet and its own customers, but some prescriptions required all three: Renhe supplied atractylodes, Jishi supplied poria, Tongchun supplied licorice root. Only with all three could you fill a complete prescription.

The trouble was in the bookkeeping.

The three shopkeepers originally shared one large ledger, kept at the teahouse in the town square. Whoever completed a transaction walked over and wrote a line. But the three shops together did over a hundred transactions a day — the teahouse ledger couldn’t keep up, and neither could the shopkeepers’ legs. Worse, sometimes two clerks arrived at the teahouse at the same time, fought over the brush, and wrote on the wrong line — a purchase of tangerine peel ended up under poria, and at audit time nobody could tell what came first.

The town elder suggested: “Let the magistrate’s office assign serial numbers. Come to the office for a number before each transaction; sort by number and you know the order.”

They tried for three days. The office had one numbering book. All three shops queued for numbers, and the line stretched to the end of the street. Getting a number took longer than the transaction itself — a three-coin sale of licorice root cost half an hour of queuing.

Then old shopkeeper Master Lu thought of a different approach. He said:

“No teahouse, no magistrate. Everyone keeps their own ledger.”

The rules were these. Each shop hung three small wooden tablets, labeled “Renhe,” “Jishi,” and “Tongchun.” Every time a shop completed one of its own transactions, it incremented the number on its own tablet by one. The three tablets together formed a tuple — for instance, Renhe Hall’s tablets might read “Renhe 7, Jishi 3, Tongchun 5,” meaning: Renhe has done 7 of its own transactions, it knows Jishi has done at least 3, and it knows Tongchun has done at least 5.

The key was in the “passing of word.”

The three shops sometimes sent herbs to each other. When Renhe sent atractylodes to Jishi, it copied its three tablet numbers onto the delivery slip. When Jishi received the delivery, it compared tablet by tablet: the slip says Renhe 7 but Jishi’s own record says Renhe 5 — so Renhe did two more transactions that Jishi didn’t know about; update to 7. The slip says Tongchun 5 and Jishi’s record also says 5 — no new information, leave it. Then Jishi incremented its own tablet by one, making “Renhe 7, Jishi 4, Tongchun 5.”

The most elegant part was determining order.

At year-end audit, the town elder asked: “Renhe’s star anise purchase and Tongchun’s licorice sale — which came first?”

Master Lu said: “Look at the tablet numbers for each. Renhe’s transaction reads (8, 3, 5) and Tongchun’s reads (7, 3, 6). Renhe’s 8 is greater than 7, but Tongchun’s 5 is less than 6 — not every number is greater, and not every number is smaller. This means the two transactions have no causal relationship. They happened concurrently; neither came before the other.”

The elder asked again: “What about the prescription Jishi filled after receiving Renhe’s atractylodes?”

Master Lu said: “Renhe’s delivery was recorded as (7, 3, 5). Jishi’s prescription was recorded as (7, 4, 5). Every number in Jishi’s tuple is greater than or equal to Renhe’s — this means the prescription definitely happened after the delivery. The causal relationship is crystal clear.”

The elder’s eyes lit up: “So your three tablets are not recording time — they are recording who knows what.”

Master Lu nodded: “Time can lie — each shop’s hourglass runs at a different speed. But who knows what — that cannot be faked.”

— By now you have probably recognized it: the three tablets are a vector clock, each tablet number is a node’s logical counter, the numbers copied onto the delivery slip are the vector piggybacked on a message, taking the larger value tablet by tablet is merge, incrementing your own is tick, “every number greater or equal” is happens-before (causal ordering), and “neither all greater nor all smaller” is concurrent. This is the story of vector clocks and causal ordering.

What it is

A vector clock is a logical clock used in distributed systems to track causal relationships between events. Each node maintains a vector (of length equal to the number of nodes), where the i-th component records how many events that node “knows about” from node i.

There are only three core operations:

1. Tick: when a local event occurs, increment your own component by 1.
2. Send: when sending a message, attach the current vector.
3. Merge: when receiving a message, take the component-wise max of your vector and the message’s vector, then increment your own component by 1.

Causal ordering rules:

• If every component of vector A is ≤ the corresponding component of B, and at least one is strictly less → A happens-before B (A causally precedes B).
• If neither A ≤ B nor B ≤ A → A and B are concurrent (no causal relationship).

A Lamport clock uses only a single scalar counter. It can establish one direction of happens-before, but cannot distinguish “no causal relationship” from “causal” — two unrelated events may receive the same Lamport timestamp. A vector clock uses N components to solve this: it tells you precisely whether two events are causally related or truly concurrent.

Amazon DynamoDB’s early design used vector clocks to detect write conflicts; Riak used them for sibling conflict detection. In practice, vectors grow linearly with node count, which led to compressed variants like dotted version vectors and interval tree clocks.

Why it matters

Distributed systems have no global clock. Physical clocks drift — two machines’ “now” can differ by tens of milliseconds, enough to reverse causality in a microservice call chain. NTP corrects drift but does not guarantee monotonicity; Spanner uses atomic clocks to compress uncertainty to microseconds, but at extreme cost.

Vector clocks sidestep physical time entirely and track “who knows what” — which is the true essence of causality. They answer not “what time did this happen” but “could this event possibly have influenced that one.”

This distinction is critical for conflict resolution. If two writes are happens-before, the later one can safely overwrite the earlier (last-writer-wins is safe). If they are concurrent, the system must preserve both versions and let the application decide — picking one arbitrarily means losing data. Vector clocks are the only mechanism that can tell you “should I overwrite or should I keep both.”

Metaphor mapping

• Three apothecary shops — three nodes in a distributed system
• Three wooden tablets per shop — vector clock (each node’s vector)
• Incrementing your own tablet — tick (local event counter +1)
• Copying tablet numbers onto delivery slips — piggybacking the vector on messages
• Taking the larger value tablet by tablet on receipt — merge (component-wise max)
• “Every number greater or equal” — happens-before (causal relationship holds)
• “Neither all greater nor all smaller” — concurrent (no causal relationship)
• Shared ledger at the teahouse — single-point centralized ordering (unscalable)
• Magistrate’s serial numbers — Lamport clock (scalar; cannot distinguish concurrency)
• “Time can lie but who-knows-what cannot” — logical clocks vs. physical clocks