What is Two-Phase Commit for Distributed Transactions?
Learn how two-phase commit (2PC) coordinates atomic commits across distributed databases, its prepare/commit phases, and its blocking risk.
Expected Interview Answer
Two-phase commit (2PC) is a protocol that lets a coordinator get multiple independent database participants to agree on committing or aborting a single distributed transaction atomically, using a prepare phase followed by a commit phase.
In the prepare (voting) phase, the coordinator asks every participant to lock its resources, write an undo/redo log, and reply yes or no without yet committing. Only if every participant votes yes does the coordinator move to the commit phase and tell everyone to make the change permanent; if any participant votes no, or times out, the coordinator broadcasts abort and everyone rolls back. The protocol guarantees atomicity across nodes, but it is blocking — if the coordinator crashes after participants have voted yes but before the final decision arrives, those participants must hold their locks and wait, which hurts availability.
- Guarantees atomic commit or abort across independent nodes
- Prevents partial commits that leave data inconsistent
- Well-understood, widely implemented (e.g. XA transactions)
- Gives a deterministic recovery protocol after crashes
AI Mentor Explanation
Picture a rain-affected match where the umpires must poll the two captains and the match referee before confirming a Duckworth-Lewis result: each side first confirms it accepts the revised target, and only when all three say yes does the umpire officially declare the result final. If even one party objects, the announcement is withheld and the previous state stands. Two-phase commit works the same way — a coordinator collects a yes vote from every database node before telling any of them to make the change permanent.
Step-by-Step Explanation
Step 1
Coordinator sends prepare
The coordinator asks every participant node to lock resources, write undo/redo logs, and vote yes or no.
Step 2
Participants vote
Each participant replies yes if it can guarantee the commit, or no if it cannot, without applying the change yet.
Step 3
Coordinator decides
If all votes are yes, the coordinator decides commit; if any vote is no or times out, it decides abort.
Step 4
Coordinator broadcasts outcome
The coordinator sends commit or rollback to every participant, which then finalizes the decision and releases locks.
What Interviewer Expects
- Clear explanation of the prepare (vote) phase and commit phase
- Understanding that all participants must vote yes before any commits
- Awareness that 2PC is blocking if the coordinator fails after voting
- Comparison to alternatives like the Saga pattern for long-lived transactions
Common Mistakes
- Describing 2PC as a single-phase broadcast rather than vote-then-commit
- Not mentioning the blocking problem when the coordinator crashes mid-protocol
- Confusing 2PC with eventual consistency or asynchronous replication
- Failing to explain why participants must hold locks during the prepare phase
Best Answer (HR Friendly)
“Two-phase commit is a way to keep a transaction that spans multiple databases all-or-nothing. First, a coordinator asks every database involved to confirm it is ready to commit, and only if everyone says yes does it tell them all to actually commit; if anyone says no, everyone rolls back together.”
Code Example
-- Coordinator starts a global (XA) transaction
XA START 'txn-42';
-- Branch on Database A
UPDATE Accounts SET balance = balance - 500 WHERE account_id = 1;
XA END 'txn-42';
XA PREPARE 'txn-42'; -- Database A votes: ready to commit
-- Branch on Database B
UPDATE Accounts SET balance = balance + 500 WHERE account_id = 2;
XA END 'txn-42';
XA PREPARE 'txn-42'; -- Database B votes: ready to commit
-- Only after BOTH branches prepare successfully:
XA COMMIT 'txn-42'; -- issued against both A and B
-- If either PREPARE fails, issue XA ROLLBACK 'txn-42' on both insteadFollow-up Questions
- What happens if the coordinator crashes after participants vote yes but before the final decision?
- How does three-phase commit try to fix the blocking problem in 2PC?
- Why do many modern distributed systems avoid 2PC in favor of the Saga pattern?
- What is the role of a transaction manager in XA-style two-phase commit?
MCQ Practice
1. In two-phase commit, when does the coordinator send the final commit instruction?
The coordinator waits for a unanimous yes vote from all participants before deciding to commit; any no vote leads to abort.
2. What is the main drawback of two-phase commit?
Participants that voted yes must hold locks and wait for the coordinator; if it crashes, they are blocked until it recovers.
3. What does a participant do during the prepare phase?
A participant readies itself to commit and reports its vote, but withholds actually applying the change until the final decision.
Flash Cards
What is two-phase commit? — A protocol where a coordinator collects yes/no votes from all participants before committing a distributed transaction atomically.
What happens in the prepare phase? — Each participant locks resources, logs the pending change, and votes yes or no without applying it yet.
Main weakness of 2PC? — It is blocking — participants that voted yes must wait if the coordinator crashes before the final decision.
What is XA? — A standard protocol/API for coordinating two-phase commit across heterogeneous resource managers like databases and message queues.