What is the two-phase commit (2PC) protocol?

The Two-Phase Commit (2PC) protocol ensures atomic commit across multiple distributed nodes — all commit or all rollback. Used when a transaction spans multiple databases or services. Participants: coordinator (transaction manager) and participants (resource managers — databases). Phase 1 — Prepare: coordinator sends "Prepare" to all participants; each participant executes the transaction locally but doesn't commit — writes to WAL, acquires locks; each participant responds "Yes, I can commit" or "No, I cannot commit." Phase 2 — Commit/Abort: if all participants voted Yes → coordinator sends "Commit" → all participants commit and release locks; if any participant voted No → coordinator sends "Abort" → all participants rollback. Problems with 2PC: (1) Blocking: if the coordinator crashes after Phase 1 but before Phase 2, participants are stuck waiting with locks held — the system is blocked until the coordinator recovers; (2) Latency: two network round trips per transaction — slow; (3) Single point of failure: coordinator failure blocks the system. Alternatives: Saga pattern (eventual consistency, no distributed locks), 3PC (three-phase commit — adds pre-commit phase to avoid blocking, but not widely used), consensus-based protocols (Paxos, Raft — for replicated state machines). When 2PC is used: relational databases (XA transactions), some distributed databases, financial systems where ACID across services is required. The CAP theorem explains why 2PC is unavailable during network partitions.