I/D/E · Visual explainer

Two-Phase Commit

Summary

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.
Distributed Transaction Request Coordinator (Transaction Manager) P1 (DB1) Account A P2 (DB2) Account B P3 (DB3) Audit Log Transfer $100: A to B, log in P3 Phase 1: PREPARE - Can You Commit? Coordinator PREPARE PREPARE PREPARE P1 Checking... P2 Checking... P3 Checking... PHASE 1 Participants Vote: All YES Coordinator 3/3 YES YES YES YES P1 Voted YES P2 Voted YES P3 Voted YES PHASE 1 All must vote YES to proceed Phase 2: COMMIT! COMMIT All YES - Commit! COMMIT COMMIT COMMIT P1 Committing... P2 Committing... P3 Committing... PHASE 2 All Participants Committed Complete TXN DONE ACK ACK ACK P1 Done P2 Done P3 Done Atomic Transaction Complete
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

Participants Vote: YES or NO

Each participant responds with its vote:

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

The coordinator waits for all votes. This is the vulnerability window — if the coordinator crashes now, participants are stuck waiting with locks held.

  • Unanimous YES required for commit
  • Single NO means abort
  • Participants hold locks while waiting

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 decision before sending
  • Participants are obligated to commit
  • Recovery uses the commit log

All Participants Committed

Each participant commits, releases locks, and sends an ACK to the coordinator. The distributed transaction is now atomically complete — all databases are consistent.

If any ACK is lost, the coordinator will retry until confirmed.

  • Atomicity achieved across multiple systems
  • All or nothing guarantee
  • Trade-off: availability and latency

What's Next?

Now that you understand two-phase commit, explore related patterns: Raft Consensus for leader-based agreement, Eventual Consistency for weaker but more available guarantees, and ACID Transactions for the properties 2PC provides.