The bookkeeper
One character standing on three machines.
Watch this caseThe situation
A shop runs three tills, each on its own machine, and every till has to show the day's running total fresh to the second. The usual answer is a second system beside the application for the three tills to agree on a number, plus the code that keeps everything in step. This case does it with no second system and no synchronization code, and the difference is a single word in a declaration.
Walk it one step at a time.
- 01Three machines open · a different cashier on each
- 02The bookkeeper is declared — one word, and not one verb changes
- 03He appears on machine one as the Director, the only one who writes
- 04The same character appears twice more: a Cast on machine two, a Cast on machine three
- 05The three stand together — and they are one character
- 06① Cashier two sells 2 · ② it reaches his local bookkeeper
- 07③ The Cast forwards it to the Director
- 08④ The Director writes add(2) · the record replicates to both Casts
- 09Ask any of the three — they all answer the same: six
What actually crosses between machines.
Journal records, Director to Cast. Each verb is defined once and everything after it is a compact invocation carrying only its arguments — measured at 33 to 96.7 bytes per event across three verb tiers, against 118 to 911 bytes for the same events written out in full.
Nothing. The answer comes from the memory of the machine you asked on, because that body had already applied the story.
None. No locks, no merge, no reconciliation — nothing written to keep the three in step. Declaring him a Stage and deploying him on three machines is still deployment work; what vanishes is the synchronization code.
Replication here is not copying state. It is sharing history.
The objection
If the local bookkeeper on my machine is a Cast, and a Cast is barred from writing, how does my sale ever get recorded? Doesn't the sale simply fail?
The Cast is not asked to write, it forwards. The command travels to the Director, the Director writes it once, and the record comes back. The counter never waits on a shared lock, and no two machines ever try to write the same total.
Words used precisely
- Applying is not recalculating
- A Cast is handed the story and applies it. It never works the total out again for itself.
- Current state is not thrown away
- The bookkeeper does hold the total in memory — that is why the answer is instant. What crosses between machines is not that total; it is the history that produces it.
- 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 reaction. Nothing watched a journal and responded.
- No message between actors.
- No locks, no merge, no reconciliation — nothing written to keep the three in step.
- No second system standing beside the application.
That absence is the result, not the setup.