2PC coordinates atomic commit across N databases. It works. But it blocks on coordinator failure — a critical drawback that led to alternatives.

CoordinatorParticipant AParticipant BParticipant CPREPAREVOTE YESCOMMITACKOR: ABORTBlocking riskif coord diesPhase 1: preparevotePhase 2: commit/abort
2PC: coordinator asks all to prepare, then commits or aborts based on votes
Advertisement

Phase 1: Prepare

Coordinator sends PREPARE. Each participant votes YES (locked resources, ready) or NO. Response persisted before reply.

Phase 1: Prepare

Coordinator sends PREPARE. Each participant votes YES (locked resources, ready) or NO. Response persisted before reply.

Advertisement

Phase 2: Commit or Abort

All YES → coordinator sends COMMIT. Any NO → sends ABORT. Participants apply + release locks.

The blocking problem

If coordinator dies between Phase 1 and Phase 2, participants holding locks don't know whether to commit or abort. They're stuck.

3PC as improvement

Three-phase commit adds a PRE-COMMIT step. Non-blocking under coordinator failure but complex + still has failure modes.

Modern alternatives

Saga pattern (compensating transactions) + async event-driven flows. 2PC still used in relational DBs but rare in microservices.

2PC gives atomicity + blocks on coordinator failure. Sagas + event-driven design usually preferred now.