What 2PC tries to do
Two-Phase Commit — all participants agree to commit or all abort:
- Prepare — coordinator asks: can you commit? Participants vote yes/no, hold locks.
- Commit — if all yes, coordinator sends commit; else abort.
Atomicity across multiple resource managers (classic XA transactions across two databases).
Why it's problematic
| Problem | Consequence |
|---|---|
| Blocking | If coordinator crashes after prepare, participants hold locks waiting forever |
| Availability | One slow/failed participant blocks everyone |
| Operational | Rare in polyglot microservices; coupling at commit time |
3PC reduces blocking with extra phase — adds complexity, not widely adopted in interviews.
Where 2PC still appears
- Distributed SQL (some internal commit protocols)
- Legacy enterprise XA across two RDBMS
- Verbal contrast: "we don't do 2PC across 12 microservices; we use sagas"
vs single-database transactions
BEGIN … COMMIT on one Postgres — not this topic. Distributed means multiple independent failure domains.
Interview framing
"2PC gives atomicity but hurts availability and blocks on coordinator failure. At scale we prefer eventual consistency with sagas or outbox for cross-service workflows."