The Runtime Theory

Distributed Transaction Commit: Shard Writes, Quorum Reads, and Atomic Visibility

Trace a multi-shard transaction from coordinator begin through quorum writes, pending intents, commit log, and atomic visibility — including abort cleanup.

The Runtime Theory Team08 stages

trace / request.md

TRANSACTIONBEGINSWRITES HIT SHARDSQUORUM DURABILITYINTENTSARE MARKEDQUORUM READSCOORDINATORCOMMITSATOMIC VISIBILITYABORT AND GC

readyThe client contacts a coordinator and receives a global transaction ID. Every subsequent operation carries that ID; the coordinator is the transaction's memory.

A multi-shard transaction is an atomicity problem with no single machine. The coordinator provides the memory — one global transaction ID that every shard's log references. Each shard owns its slice of the transaction and makes its writes durable independently, but visibility is withheld: writes exist as intents, readable only by their own transaction, until the coordinator's decision.

Quorum arithmetic is what makes reads honest. R replicas per read and W per write, with R+W exceeding N, guarantee the read set intersects the write set — so a stale read is geometrically impossible rather than merely unlikely. The commit is the moment the intents flip: a shard-local, atomic transition from hidden to visible, sequenced by the coordinator's logged decision. That is the ordering that matters — durably write, then decide, then reveal. Aborts work in reverse: discard the intents everywhere. The transaction's end state — fully visible or fully absent — holds on every shard, which is the entire contract of a distributed transaction.