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.
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 reaction watched a journal, no character told another character anything, and nobody wrote a line of synchronization code.
Replication here is not copying state. It is sharing history.
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.
- 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.
- No reaction. Nothing watched a journal and responded.
- No message between actors.
- No line of synchronization code.
- No second system standing beside the application.
That absence is the result, not the setup.