Three-Phase Commit (3PC)

Three-Phase Commit (3PC) extends 2PC with a "pre-commit" phase to reduce blocking when the coordinator fails.

The Problem with 2PC

In 2PC, if the coordinator fails after participants vote "yes" but before sending commit, participants are blocked - they don't know whether to commit or abort.

3PC Solution

Adds a pre-commit phase so participants know the decision before committing.

Phases

1. CanCommit: Coordinator asks if participants can commit (same as 2PC prepare)
2. PreCommit: If all vote yes, coordinator sends pre-commit (participants know commit is coming)
3. DoCommit: Coordinator sends commit, participants commit

Key insight: If coordinator fails in phase 2, participants know commit was decided and can safely commit.

Implementation

1 

Common Pitfalls

• Still requires all nodes: Network partitions still problematic
• More complex: Three phases instead of two
• Not widely used: Most systems use 2PC or alternatives like Saga
• Timeout handling: Must handle timeouts in each phase

Interview Questions

Beginner

Q: How does 3PC differ from 2PC?

A: 3PC adds a "pre-commit" phase between prepare and commit:

2PC: Prepare → Commit/Abort 3PC: CanCommit → PreCommit → DoCommit

Benefit: If coordinator fails after pre-commit, participants know commit was decided and can safely commit (non-blocking). In 2PC, they would be blocked.

Intermediate

Q: When would you use 3PC over 2PC?

A: Use 3PC when:

• Coordinator failures are common: Need non-blocking behavior
• Can tolerate extra round trip: 3PC has higher latency (3 phases)
• Need better fault tolerance: Participants can recover without coordinator

However, 3PC is rarely used in practice because:

• Still not partition-tolerant: Requires all nodes reachable
• More complex: Harder to implement and debug
• Alternatives exist: Saga pattern, Paxos/Raft often better choices

Recommendation: Use 2PC for simple cases, or consider Saga/Paxos for better fault tolerance.

Senior

Q: Design a 3PC system that handles coordinator failures. How do participants recover and ensure consistency?

A:

1 

Consistency guarantees:

• Pre-committed state: All participants that reach pre-committed know commit was decided
• Recovery protocol: Participants can query each other to determine decision
• Majority rule: If majority is pre-committed, decision was commit