Three Machines, One Paper
A clinic with four consulting rooms needs one appointment book that every machine can read, and today that costs either a subscription — with the records held elsewhere and a front desk that stops when the connection drops — or a database and an application server on the premises and somebody to keep them alive. Neither cost comes from the clinic; both come from the stack. This experiment takes a piece of Microsoft's reference microservice application, puts it on a program that keeps its own journal, and runs it on three machines that admit each other with a QR code printed on paper.
Is the datacenter a structural requirement of running production software, or a requirement of the habitat the software is conventionally solved inside — a database to operate, an application server, an orchestration cluster, a platform for watching all of it?
The Ordering bounded context of Microsoft's dotnet/eShop reference application, a widely used example of microservice-oriented cloud architecture. The aggregate, the value objects, the lifecycle verbs and the invariants moved without modification. The lines that could not be hosted as they were are a small minority, concentrated in the glue for persistence and deployment. What had been called the Ordering microservice turned out to be a clean domain library wrapped in infrastructure that was compensating for a way of storing things that kept only the latest state, not how it got there; the port separated the two.
A new peer joins in five phases. Two of them are not software at all.
- The issuer opens an invitation.
- The invitation travels to the joining peer by whatever means the operator picks. Here it was printed on paper, as a QR code.not software — the operator chooses the carrier
- The joining peer opens an encrypted connection back.
- Everything pauses for a human to approve or reject the join.not software — a person decides
- A credential is sealed to the joining peer's own key, and the handshake closes.
Phases one, three and five are genuinely server-like: the issuer listens on an address, accepts a connection, and seals a credential. All three are local to the issuer process, and that process exits when the bootstrap is done. Afterwards it is not a server, a coordinator, an authority, a registry or a rendezvous point.
Three peers, every pair connected — three being the smallest number at which no pair dominates the third.
- No surviving network path connects the containers to the issuer. The bootstrap papers are in a drawer.
- None of the services that originally constituted the Ordering microservice is reachable from the cluster. Not one.
- The cluster continues to function under each one's absence. Stop a container and the other two keep accepting work; start it again and it rehydrates from its own volume and catches up against a surviving peer.
The same workload runs four times, across two axes. Each cell is the number of journal entries the workload ends at.
| Scripts written out literally | Values carried separately | |
|---|---|---|
| Inside one operating-system process | 22 | 7 |
| Across three containers, real encryption, paper bootstrap | 22 | 7 |
The count is identical in all four combinations, and the three peers are byte-coincident on disk. That is what the four cells are for: one process isolates what the journaling does on its own, and three containers show those properties survive a real cryptographic stack and a bootstrap that travelled on paper.
- It does not solve consensus. The machinery does not elect anybody, does not vote, keeps no term or epoch numbers and provides no fencing tokens; promotion is a decision made from outside, and the new identity spreads by best-effort announcement.
- The rotation used here is one peer-coordination mechanism chosen for the demonstration, not a property of the actor model.
- The experiment is at three peers. Whether that mechanism scales operationally to larger numbers is engineering work nobody has done here.
- The original resolves identity through an external provider; the port substitutes a local string-typed identifier.
- The references Ordering resolves through the Catalog and Basket contexts are treated as opaque identifiers.
What is established is a structural permission, through one working case — not an appliance delivered end to end to a customer.