Three-phase commit (3PC).

3PC, proposed by Dale Skeen in 1981, is the direct, deliberate fix for 2PC's blocking problem (article 4.4) — and it genuinely works, under one specific, limited failure assumption: crash failures only, with no network partitions. The fix is elegant: insert a third phase (pre-commit) that gives every participant enough shared information to safely make a unilateral decision if the coordinator disappears, without needing to guess. But — and this "but" is the entire reason this article exists as the closer for Phase 4 — the moment you introduce network partitions into the failure model (article 1.1's actual, realistic assumption for any real network), 3PC's fix breaks down and can produce a genuine safety violation, not just blocking. This is the precise, well-documented gap that finally, definitively motivates majority-quorum-based consensus — the subject of every remaining phase from here on.

The fix: an extra phase for shared certainty

Recall exactly where 2PC's blocking problem came from (article 4.4): a participant that voted commit has no way to know, from local information alone, whether the coordinator's actual final decision was commit or abort, when the coordinator disappears after deciding but before announcing. 3PC's insight: insert an intermediate phase that ensures no participant is ever asked to commit without every other prepared participant also having heard, at minimum, that a decision is imminent — closing the specific information gap that made 2PC's participants unable to resolve their uncertainty locally.

Phase 1: CanCommit (same as 2PC's prepare-vote)

Identical to 2PC's Phase 1 — the coordinator asks, participants vote commit or abort based on local readiness.

Phase 2: PreCommit (the new phase)

If every participant voted commit, the coordinator sends PRE-COMMIT (not yet the final commit) to everyone, and waits for acknowledgment. This step's entire purpose: by the time any participant receives a PRE-COMMIT, it now knows, with certainty, that every other participant also voted commit — a fact no participant in plain 2PC ever gets access to before the final decision. Participants acknowledge receipt.

Phase 3: DoCommit

Once the coordinator has collected acknowledgments from the pre-commit round, it sends the final DO-COMMIT, and participants actually apply the change.

Phase 1 (CanCommit):   coordinator -> participants: CAN-COMMIT?
                        participants -> coordinator: YES / NO

Phase 2 (PreCommit):   coordinator -> participants: PRE-COMMIT   (only if all said YES)
                        participants -> coordinator: ACK

Phase 3 (DoCommit):    coordinator -> participants: DO-COMMIT
                        participants -> coordinator: ACK

Why the extra phase actually prevents blocking under crash-only failures

Here's the precise mechanism, worth walking through carefully because it's genuinely clever. Suppose the coordinator crashes after sending PRE-COMMIT to some (or all) participants, but before sending the final DO-COMMIT. Every participant that received the pre-commit message now knows, with certainty, that every participant voted commit in Phase 1 — because the coordinator would never have sent pre-commit otherwise. Armed with this shared knowledge, the participants can run a sub-protocol among themselves (elect a new coordinator from among the participants, ask around what state everyone reached) and safely decide to commit unilaterally — they know, from the pre-commit message alone, that committing is the correct, universally-safe choice, without needing to hear from the original crashed coordinator at all.

Symmetrically, if a participant crashed before ever receiving a pre-commit message, the remaining live participants can safely conclude the transaction never reached unanimous agreement, and abort — again, without needing the original coordinator's input, because the pre-commit message's absence is itself decisive information.

Why network partitions break 3PC anyway

Here's the crucial qualifier this whole article has been building toward, and it's the single most important lesson of Phase 4's closing article: 3PC's fix explicitly assumes crash failures only — a process that stops is gone for good (or recovers with all the same information intact), and critically, every live participant can always reach every other live participant. This is precisely the assumption article 1.1 spent its entire length arguing is unrealistic for any real network — a partition (not a crash) can split participants into groups that can talk within the group but not across groups, and this is exactly the scenario 3PC cannot safely handle.

Concretely: suppose a partition splits the participants into two groups right after some, but not all, participants received PRE-COMMIT. One group — the one that received pre-commit — reasonably concludes (per the mechanism above) "everyone voted commit, we should proceed and commit." The other group — which never received pre-commit before the partition — has no such information, and by the same logic used above, might reasonably conclude "we can't confirm a pre-commit happened, we should abort, to be safe." Both groups follow 3PC's own recovery logic correctly, and reach opposite decisions. This is a genuine safety violation — part of the transaction commits, part aborts — which is strictly worse than 2PC's blocking, because blocking (a liveness failure, per article 4.1) never actually corrupts data, while this partition scenario does.

Why this gap is exactly what majority-quorum consensus was built to close

This is the payoff for the entire phase, and it should now land with full force: the partition-safety failure above happens precisely because 3PC's recovery logic lets each side of a partition act independently, with no requirement to check whether it constitutes a majority. Article 3.3's core proof is the exact, structural fix — require a majority (not "everyone," not "whichever side happens to have more information") before any side is allowed to proceed, and the overlap guarantee makes it mathematically impossible for two disjoint groups to both believe they have that majority. 3PC's designers were solving a real, important problem (blocking under crashes), but the fix they built doesn't survive contact with the failure model this entire series has insisted on since article 1.1 — and that gap is not a minor footnote, it is the historically documented reason the field moved toward Paxos (1989/1998) and its descendants as the actually-robust answer.

Closing Phase 4

Phase 4 built the last conceptual layer before real algorithms: safety vs. liveness as formal, distinct property classes (4.1); leader election as a liveness mechanism riding safely on top of majority-overlap-guaranteed safety (4.2); the formal equivalence between consensus, SMR, and atomic broadcast (4.3); and the two historical commit protocols (4.4, 4.5) whose well-documented, precisely-understood failure modes are exactly what majority-based consensus was built to solve. Every concept from Phases 1 through 4 — the failure spectrum, replication, CAP/PACELC, clocks, failure detectors, FLP, SMR, logs, quorums, leases, safety/liveness, election, broadcast, and now the specific gap in commit protocols — converges, starting next article, into Paxos: the algorithm that got all of this right, and the one nearly everything else in this series (Phases 5 through 10) is either built on, a variant of, or a direct response to.

FAQ

Takeaways

• 3PC adds a pre-commit phase to 2PC specifically to give surviving participants enough shared information to resolve a coordinator crash without blocking — and it genuinely works, under a crash-only failure model.
• The mechanism: a participant that received PRE-COMMIT knows with certainty everyone voted commit; a participant that didn't knows the transaction never reached unanimous agreement — either way, surviving participants can safely decide without the original coordinator.
• Network partitions break this fix — two disjoint groups can each follow 3PC's own recovery logic "correctly" and reach opposite decisions, producing a genuine safety violation (worse than 2PC's mere blocking).
• This happens because 3PC's recovery logic never requires checking for a majority before a group acts independently — exactly the gap article 3.3's overlap proof exists to close.
• This precise, well-documented failure is a direct, historical part of what motivated majority-quorum-based consensus — Phase 5, starting next, covers Paxos and its descendants, which finally handle the full realistic failure model (crashes and partitions) without this trade-off.
• Phase 4 is now complete — every foundational concept from Phases 1-4 converges into the classical algorithms next.

References & further reading

• Skeen — Nonblocking Commit Protocols (1981) — the original 3PC paper.
• Lamport — The Part-Time Parliament (Paxos, 1998) — the algorithm that finally solves this gap correctly; full treatment starts Phase 5.
• cvam.sight — Consensus 1.1: Why Distributed Systems Are Hard — the realistic failure model (including partitions) 3PC's crash-only assumption falls short of.
• cvam.sight — Consensus 3.3: Quorums and Majority Voting — the exact mechanism missing from 3PC's recovery logic.
• cvam.sight — Consensus Algorithms series hub — Phase 5 (Classical Consensus — Paxos & Raft) picks up next.