Last Updated: January 15, 2026
In the previous chapter, we explored Two-Phase Commit and discovered its fundamental weakness: blocking. When a coordinator fails after participants have voted YES but before announcing the decision, participants are stuck. They cannot commit, cannot abort, and must hold their locks indefinitely while waiting for the coordinator to recover.
Three-Phase Commit (3PC) was designed specifically to address this blocking problem. By adding an intermediate phase between voting and committing, 3PC ensures that participants are never left in a state where they cannot make progress. If the coordinator fails, participants can coordinate among themselves to reach a decision.
The trade-off is additional complexity and more message round trips. In practice, 3PC is rarely used in modern systems. The added cost does not justify the benefits in most scenarios, and alternative approaches like Paxos-based consensus or Saga patterns have largely replaced it.
However, understanding 3PC provides valuable insight into the challenges of distributed coordination and why the industry moved toward eventual consistency patterns.
Let us revisit why 2PC blocks to understand what 3PC needs to solve.
The problem is that in 2PC, a participant in the "prepared" state lacks information to make a unilateral decision:
| What participant knows | What participant does not know |
|---|---|
| It voted YES | How other participants voted |
| It can commit if asked | Whether coordinator decided to commit |
| It promised to follow decision | Whether any participant failed |
If participants could somehow know that everyone voted YES before the coordinator fails, they could safely commit on their own. This is the insight behind 3PC.