Why it matters
Understanding 2PC explains why distributed transactions are hard. Every distributed system either implements a variant of 2PC or explicitly avoids it. Knowing why matters for architecture decisions.
The architecture
Phase 1 (prepare): coordinator sends PREPARE to all participants. Each participant either votes YES (durably) or NO. Coordinator collects votes.
Phase 2 (commit or abort): if all voted YES, coordinator sends COMMIT; participants commit and reply DONE. If any voted NO or timed out, coordinator sends ABORT.
How it works end to end
Atomicity guarantee: either all participants commit or all abort. Achieved because participants can't unilaterally commit or abort after voting YES.
Blocking problem: if coordinator crashes after some participants got COMMIT, others are stuck holding locks. Three-phase commit tries to fix this but is complex and rarely used.
Modern alternatives: sagas (compensating transactions), TCC (Try-Confirm-Cancel), or eventual consistency approaches.