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

1class ThreePhaseCommit {
2  async execute(participants: Participant[]):

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:

1class FaultTolerant3PC {
2  async executeWithRecovery(participants: Participant[]): Promise<void> {
3    // Phase 1: CanCommit
4    const votes = await this.canCommitPhase(participants);
5    if (!this.allYes(votes)) {
6      return this.abort(participants);
7    }
8
9    // Phase 2: PreCommit
10    await this.preCommitPhase(participants);
11
12    // Phase 3: DoCommit
13     participants

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

• 3PC reduces blocking: Participants can recover if coordinator fails after pre-commit

• Three phases: CanCommit → PreCommit → DoCommit

• Pre-commit state: Indicates commit decision was made

• Non-blocking recovery: Participants can commit independently if in pre-committed state

• Still not partition-tolerant: Requires all nodes reachable

• Rarely used: Most systems prefer 2PC or alternatives (Saga, Paxos)

• Use when: Need non-blocking behavior but still want strong consistency

• Two-Phase Commit (2PC) - Blocking alternative to 3PC

• Distributed Transactions - Transaction protocols overview

• Consensus Algorithms (Raft, Paxos) - Alternative consensus protocols

• Fault Tolerance - Handling coordinator failures

• Partition Tolerance - CAP theorem and network partitions