Two-Phase Commit has a nasty failure mode: if the coordinator dies after participants vote YES but before they hear the commit decision, they're stuck. They can't abort (someone might have committed) and they can't commit (someone might have aborted). They hold their locks and wait. Forever, in the worst case. Three-Phase Commit (3PC) was designed to fix exactly this — to make consensus non-blocking when the coordinator fails.

3PC splits the commit into three phases instead of two:

• CanCommit: Coordinator asks participants if they could commit. Participants reply YES/NO but don't lock anything permanently.
• PreCommit: If everyone said YES, coordinator sends PRE-COMMIT. Participants acknowledge and now know that everyone has agreed. This is the key insight — the pre-commit phase spreads knowledge of the decision.
• DoCommit: Coordinator sends the actual commit. Participants commit and reply.

The magic is in the recovery rule: if the coordinator dies, participants can elect a new coordinator and reach a safe decision by themselves. If any participant reached the PreCommit state, the new coordinator commits. If none did, it aborts. No more indefinite blocking.

Real-world example: Imagine a distributed order system booking a flight, hotel, and rental car atomically. In 2PC, if the coordinator crashes right after everyone votes YES, all three services hold locks on inventory. The flight seat, hotel room, and car sit unbookable until someone manually intervenes. In 3PC, once the coordinator sends PRE-COMMIT, any surviving participant can drive the transaction to completion — the seat gets booked or released within seconds of the failure.

Rule of thumb: 3PC costs you 50% more network round trips than 2PC (three phases instead of two). On a system with 10ms inter-node latency, a 2PC transaction takes ~40ms (two round trips) while 3PC takes ~60ms. That's a significant tax for every transaction to protect against a rare failure mode.

Here's the catch nobody tells you: 3PC assumes a synchronous network with bounded message delays. In real networks, a slow participant is indistinguishable from a dead one, and 3PC can produce inconsistent decisions during network partitions. That's why production systems (Spanner, CockroachDB, etcd) use Paxos or Raft instead — they handle partitions correctly and only pay the extra round trip when actually needed.

3PC is a beautiful academic protocol that taught us why consensus is hard, but its assumptions don't hold in production networks.