Understanding Distributed Consistency and the Two-Phase Commit Protocol

The piece uses a restaurant kitchen and a five‑person gaming session as analogies to illustrate distributed consistency: when multiple independent participants must cooperate, missing or delayed communication can cause inconsistent states, just like a partial order in an e‑commerce system.

To guarantee consistency, a coordinator role is introduced, which mirrors the X/Open distributed transaction model; the two‑phase commit (2PC) protocol is derived from this model.

In the analogy, the organizer acts as the coordinator, sending a "prepare" request to each participant (players). Participants respond with either agreement (ready) or abort (cannot join). This constitutes the first, preparation (voting) phase.

If all participants agree, the coordinator proceeds to the second, commit phase, sending a commit message that lets everyone enter the game (finalize the transaction). If any participant aborts or a timeout occurs, the coordinator issues a rollback, and all participants cancel their actions.

The article enumerates the detailed steps of the prepare phase—querying readiness, logging undo/redo information, and collecting votes—and the commit phase—issuing commit or rollback commands and handling acknowledgments.

Finally, the drawbacks of 2PC are discussed: synchronous blocking of all participants, a single point of failure at the coordinator, possible data inconsistency when messages are lost, and the inability to resolve failures that occur after the commit message is sent.

Overall, the article provides a clear, example‑driven explanation of distributed transaction coordination and highlights why 2PC, while foundational, is not a perfect solution.