The situation
Three tills and one of the oldest problems in distributed systems: the things every machine must agree on. The price list. The catalogue. Who counts as a member. The textbook answer gives those a category of their own — coordination state — and then a home of their own: a second system beside the application, plus a cache, an invalidation rule and a job that reconciles when the two drift. This case claims that middle category does not need to exist.
Walk it one step at a time.

- 01Three tills open · each cashier with his own journal
- 02The clerk is declared — one word, and he stands on machine one as the Director
- 03His journal turns out to BE the price list — and what he is not authoritative about
- 04A Cast on machine two, a Cast on machine three — the three are one clerk
- 05① The change lands on machine two · ② the Cast forwards it · ③ the Director writes it
- 06④ It replicates to both Casts · ⑤ a local reaction fires on each — and not instantly
- 07⑥ Cashier two sells and captures the price he charged — capturing is not caching
- 08The boundary: catalogue yes, liveness no
What actually crosses between machines.
A command forwarded to the Director, then compact records out to every replica.
Nothing. The reaction that fires when a price changes never touches the network, because the clerk was already there.
The consumed value is frozen into the consumer's own journal entry, the way a timestamp is frozen. A replay five years later never asks the clerk anything.
The clerk is a source of knowledge, not a source of historical truth.
The objection
If the price lives in a replica, and a replica can be a moment behind the Director, a till could sell at the old price. Isn't that a bug you designed in?
It is a real property, worth stating rather than waving away: two machines can capture different prices for what looks like the same logical moment. What does not break is honesty — every sale records exactly the price it used, and every replay reproduces exactly that sale. Where that is genuinely unacceptable there is a knob: a decision that needs a linearized read pays the trip to the Director and gives up the free local read.
Words used precisely
- Capturing is not caching
- A cache is asked again and can answer differently the second time, which is what makes a replay drift. A captured value was asked once and became part of the sentence that was written down. It cannot answer differently later, because it is no longer answering.
- The Director writes, a Cast applies
- A Cast does not compute its own version of the price list. It applies the same record, in the same order.
- You do not operate any of this
- You declare the character and write ordinary commands; which of the replicas writes is the engine's election, not a line in your code. The machinery is shown here for the same reason a database's transaction log is documented: not because you drive it, but because a claim about coordination you cannot inspect is one you have to take on faith.
What is absent
- No coordination service standing beside the application.
- No cache, and therefore no invalidation rule.
- No reconciliation job for when the two copies drift.
- No synchronization code written by anybody.
That absence is the result, not the setup.