Two-Phase Commit

How distributed systems achieve atomic transactions across multiple databases using the 2PC protocol.

Read this as How do participants reach one atomic commit or abort decision?
Failure Trap
Forgetting that 2PC can block when the coordinator fails at the wrong time.
Decision Rule
Use 2PC for short atomic boundaries; prefer sagas or idempotent recovery for long-running workflows.
Two-phase commit protocol A coordinator runs a distributed transaction over three database participants in two phases. Phase 1: the coordinator sends PREPARE and each participant votes YES or NO while holding locks. Phase 2: if every vote is YES the coordinator broadcasts COMMIT and all participants commit atomically; a single NO forces a global ABORT, and a coordinator crash mid-vote leaves participants blocked holding their locks. Distributed Transaction Coordinator Transaction Manager P1 · DB1 Account A P2 · DB2 Account B P3 · DB3 Audit Log Transfer $100 A → B, log in P3 All commit, or none do. Phase 1 · PREPARE Coordinator "Can you commit?" PREPARE P1 Lock + log P2 Lock + log P3 Lock + log Resources locked, not yet changed. Each decides if it CAN commit. Vote: YES or NO? Coordinator waits for all votes YES YES NO? P1 Voted YES P2 Voted YES P3 Deciding… ALL YES → commit. ANY NO → abort. Locks held till coordinator replies. Phase 2 · COMMIT All voted YES decision logged COMMIT P1 Committing… P2 Committing… P3 Committing… Coordinator logs COMMIT first. Participants must now commit. Atomic Commit Done Complete all ACKs received ACK P1 Done ✓ P2 Done ✓ P3 Done ✓ All databases consistent. Atomicity across all systems. When It Goes Wrong Coordinator crashes mid-vote ✕ NO P1 Blocked 🔒 P2 Blocked 🔒 P3 Aborts One NO → global ABORT. Coordinator crash → participants block, locks held.
1 / ?

Distributed Transaction Request

A client wants to perform a transaction across multiple databases: transfer $100 from Account A (Database 1) to Account B (Database 2), and log the transfer (Database 3).

A coordinator (Transaction Manager) orchestrates this across all participants (the databases).

  • Single transaction spans multiple systems
  • Coordinator manages the protocol
  • Either ALL succeed or ALL fail (atomicity)

Phase 1: PREPARE - Can You Commit?

The coordinator sends a PREPARE request to each participant. Each participant must:

  1. Acquire necessary locks
  2. Write a prepare record to its log
  3. Determine if it CAN commit

The participant votes without actually committing yet.

  • Resources are locked but not changed
  • "Point of no return" — once you vote YES, you must be able to commit

Vote: YES or NO?

Each participant responds with its vote:

  • YES: "I can commit if asked"
  • NO: "Something prevents me from committing"

The rule is unanimity: every vote must be YES to commit, and a single NO forces the whole transaction to abort. In the diagram, P1 and P2 vote YES while P3 is still deciding — its vote alone can flip the outcome.

The coordinator now waits for all votes. This is the vulnerability window — participants hold their locks until the coordinator replies, so if the coordinator crashes here they are stuck (see the last step).

Phase 2: COMMIT

Since all participants voted YES, the coordinator:

  1. Writes "COMMIT" to its log (point of no return)
  2. Sends COMMIT to all participants

Participants MUST commit upon receiving this — they already promised they could.

  • Coordinator logs the decision before sending
  • Participants are obligated to commit
  • Recovery replays the commit log

Atomic Commit Done

Each participant commits, releases its locks, and sends an ACK to the coordinator. The distributed transaction is now atomically complete — every database is consistent.

If any ACK is lost, the coordinator retries until confirmed.

  • Atomicity achieved across multiple systems
  • All-or-nothing guarantee

When It Goes Wrong

2PC is defined by its failure modes, not just the happy path:

  • A single NO → global ABORT. One participant unable to commit cancels the whole transaction; everyone rolls back.
  • Coordinator crash mid-vote → participants block. With the decision unknown, participants cannot safely commit or abort, so they wait — holding locks — until the coordinator recovers. This is the blocking problem that makes 2PC trade availability for atomicity.

This is the vulnerability window from step 3, made concrete.