Distributed Transactions & Two-Phase Commit
The problem
Some operations need atomicity — all-or-nothing — across multiple independent databases or services, not just multiple rows in one database, and a plain single-machine transaction has no way to coordinate a commit decision across machines that might fail independently mid-operation.
Why now
Transactions and ACID already established atomicity as a single-database guarantee; two-phase commit is the direct attempt to extend that exact guarantee across multiple machines, using the vote-then-commit shape from consensus algorithms but applied specifically to committing or aborting a transaction, not electing a leader.
Mental model
Two-phase commit splits a commit into a rehearsal and a performance: first, ask every participant 'can you commit this?' and wait for all to say yes (the prepare phase); only if everyone agreed, tell them all to actually commit (the commit phase). If even one participant votes no, everyone aborts — the same all-or-nothing guarantee as a local transaction, paid for with an extra round trip and a new failure mode if the coordinator itself dies mid-protocol.
Requires
- Transactions & ACIDDatabase Engineering
Two-phase commit exists specifically to extend the atomicity guarantee of a single-machine transaction across multiple machines; you need that guarantee's value already established before the extra protocol cost of extending it is justified.
- Consensus AlgorithmsDistributed Systems
Two-phase commit's prepare-then-commit structure is a restricted, specialized form of the agreement problem consensus algorithms solve more generally, and shares its central vulnerability — what happens if the coordinator fails mid-vote.
Used in
- Distributed transactions spanning multiple databases or services (increasingly rare in modern architecture, but foundational to understand)
- Message brokers and databases that support XA transactions
- Explaining why most modern systems prefer sagas (compensating actions) over two-phase commit for cross-service consistency
- Understanding the coordinator-failure problem as a reason two-phase commit is often avoided at scale
Projects
- Simulate a two-phase commit across three participants, including a scenario where one votes 'no' and the whole transaction aborts
- Explain what happens if the coordinator crashes after participants have voted 'yes' but before sending the commit message — and why this is a real, unresolved weakness
Examples
- A booking system reserving a flight seat and a hotel room together either confirms both or neither, coordinated via two-phase commit across two services
- If a coordinator crashes after all participants voted 'yes' but before telling them to commit, participants are stuck holding locks, unsure whether to commit or abort — the protocol's most cited weakness
Resources
Mastery checklist
- I can explain the prepare and commit phases of two-phase commit
- I can explain why a single 'no' vote must abort the entire transaction
- I can explain the coordinator-failure weakness and why it matters
- I can explain why many modern systems prefer alternatives (like sagas) over distributed transactions