11.A Promise That Spans Machines

A single order now has to touch two genuinely different machines at once: deduct stock from the inventory shard that owns this product, and create the order record on the shard that owns this customer. Act 4 already taught a conditional write keeping one item honest on one machine. This is a different, harder question: what if the deduction succeeds and the order creation fails, or the other way around?

Sarah doesn't want "probably fine." She wants a real, both-or-neither guarantee, across two machines that don't share anything except a network connection.

A distributed transaction is exactly this: a single logical operation that has to succeed or fail as one unit, across more than one machine — genuinely harder than a single-machine transaction, because there's no one place that can just lock everything and decide alone.

Two-phase commit (2PC) is the classic, real protocol for exactly this, walked through concretely above. Phase one (prepare): a coordinator asks every participant — the inventory shard, the order shard — "can you do your part of this, and are you willing to guarantee it, if asked?" Each one checks, locks what it needs, and answers yes or no, without actually committing yet. Phase two (commit or abort): if every participant said yes, the coordinator tells all of them to actually commit, for real. If even one said no, it tells all of them to abort — nothing happens anywhere, cleanly. GreenMart never ends up in the broken state where stock was deducted but no order exists, or an order exists for stock that was never actually reserved.

2PC genuinely works, and it has a real, honest weakness worth naming directly: it depends on the coordinator. If the coordinator itself fails after phase one but before telling everyone the final answer, participants are left holding a lock, genuinely unsure whether to commit or abort — blocked, potentially for a long time, waiting on a machine that might not come back. This is exactly why real consensus protocols (Raft, Paxos, from two chapters back) are often preferred for genuinely critical coordination — they're built from the ground up to keep making progress even when some machines are unreachable, rather than depending on one coordinator's own survival.

Clock/time problems and replication lag are two more, real, honest reasons distributed correctness is hard even without an outright failure. Different machines' clocks are never perfectly synchronized — "which write happened first" can't always be answered by just comparing timestamps across machines, the same real problem behind why this course's own simulator-backed Acts always used a relative or simulated clock rather than real wall-clock time. Replication lag is the honest gap between a write landing on a leader and that same write actually reaching every follower — a real, measurable delay, not an instant, and exactly the kind of gap that can turn a read against a lagging follower into a stale one, even with no partition happening at all.