How it works
Start with an invariant that spans participants. For example, moving $100 between accounts on different database shards must commit both the debit and credit, or neither. A coordinator assigns a transaction ID and tracks the participants.
Phase 1 is prepare. The coordinator asks each participant whether it can commit its part. Before voting yes, a participant durably records enough state to finish after a crash and retains the locks or other concurrency-control state required by its database. A yes vote is a promise, not a completed commit.
The coordinator chooses commit only if every participant votes yes. If anyone votes no, or preparation times out before a commit decision, it can choose abort. The coordinator durably records its decision before sending that decision to participants.
Phase 2 distributes the decision. Participants commit or abort, record the outcome, and release resources. Messages may be retried, so processing the same transaction decision again must be safe. Participants can finish at different times; 2PC does not make updates become visible everywhere at the same instant.
The hard case is a failure after a participant votes yes but before it learns the decision. That participant cannot safely abort just because a timer expires: another participant may already have committed. It must recover the decision from an authoritative source or remain prepared, potentially blocking conflicting work.
Every participant must support durable prepare and recovery; an ordinary HTTP endpoint is not enough. 2PC supplies atomic commitment, not isolation by itself. Correct reads and concurrent updates still depend on the database's concurrency-control and isolation guarantees.
A worked example
A $100 transfer across two ledger shards
Account A has $500 on shard 1; account B has $200 on shard 2. Transaction T42 stages a $100 debit and a $100 credit. Both shards check their constraints, durably prepare, and vote yes. The coordinator durably records COMMIT, then sends it to both shards. Shard 1 commits, but the coordinator crashes before shard 2 receives the message. Shard 2 must remain prepared rather than aborting after a timeout. Once the coordinator recovers its decision log, it resends COMMIT and shard 2 finishes. The final balances are $400 and $300. During recovery, conflicting operations may block, and read behavior depends on the database's isolation guarantees.
Trade-offs to say out loud
- Atomic outcome across transactional resources
- 2PC avoids permanently committing only part of a transaction, provided participants honor the protocol and their durable state remains recoverable.
- Additional latency
- Preparation and decision delivery add network coordination and durable logging to the transaction path.
- Blocking during failures
- A prepared participant may retain locks or reservations until it can learn the authoritative outcome.
- Shared availability and contention costs
- A slow or unreachable participant can delay completion and extend resource holding across otherwise healthy participants.
- Restricted participant support
- External payment APIs, email providers, and many storage interfaces cannot join a prepared transaction.
- Recovery complexity
- Operating 2PC requires durable coordinator state, safe coordinator failover, decision retries, and monitoring for unresolved prepared transactions.
When to reach for it
- A strict invariant spans multiple transactional resources, and partial completion is unacceptable.
- Related data cannot reasonably be colocated inside one database transaction.
- All participants support durable prepare, commit, abort, and crash recovery.
- Transactions are short, and the system can tolerate coordination latency and temporary blocking.
How to bring it up in the interview
- State the invariant before naming the protocol: for example, both ledger entries must commit together. First check whether data placement can make this a local transaction.
- Draw the coordinator and participants, then mark the durable prepare records and the durable commit decision. Expect the interviewer to ask what survives a crash.
- Walk through a coordinator failure after one participant receives commit. Explain why another prepared participant cannot independently abort on timeout.
- Compare 2PC with a saga explicitly: 2PC holds a distributed transaction until a shared decision, while a saga commits local steps and uses business actions to compensate for failures.
- Separate internal atomicity from external effects. A database transaction cannot force a bank API to participate; discuss idempotency, an outbox, and reconciliation at that boundary.
Common mistakes
- Treating two sequential service calls as 2PC without durable prepare support.
- Saying a prepared participant can always abort after a timeout.
- Claiming 2PC alone provides serializable isolation, simultaneous visibility, or exactly-once external side effects.
- Using 2PC for a long-running workflow involving payment providers or human actions instead of modeling explicit states and compensation.
- Calling a saga equivalent to rollback: compensation is a new business operation that can fail and may not erase effects already observed.
Where it comes up
Interview questions where two-phase commit is part of a strong answer, and why.
- Design a wire transfer systemThe atomic ledger boundary requires deciding whether debit and credit fit in one local transaction or need cross-shard commitment, separately from the external bank workflow.
- Design a stock trading app like RobinhoodCash and share reservation invariants require an explicit transaction boundary, making 2PC a key option to evaluate if authoritative records span transactional stores.
- Design a hotel booking systemAn all-or-nothing multi-night reservation requires either colocated inventory transactions or a cross-partition coordination strategy such as 2PC.
Questions people ask
What is the difference between two-phase commit and a saga?
2PC coordinates one atomic outcome across participants that support prepared transactions. A saga is a sequence of committed local transactions with compensating actions when later steps fail. Sagas suit long-running workflows and external integrations, but intermediate states are visible and compensation is not the same as database rollback.
Why is two-phase commit a blocking protocol?
After voting yes, a participant has promised to accept the eventual decision and cannot safely choose a different outcome. If it cannot recover that decision, it may have to wait while holding transaction resources. A timeout detects uncertainty; it does not prove that abort is safe.
Is two-phase commit the same as consensus?
No. 2PC coordinates commit or abort across transaction participants; consensus protocols let replicas agree on a value or ordered log despite some failures. Consensus can replicate a coordinator's decision log and improve recovery, but it does not eliminate the need to prepare every transaction participant or make unreachable participants available.