System Design Cases
Three-Phase Commit (3PC)
Three-Phase Commit (3PC) protocol — concept page. Adds PreCommit phase between Vote and DoCommit to fix 2PC blocking problem when coordinator fails. Three scenarios: (1) happy path through CanCommit/PreCommit/DoCommit, (2) coordinator failure after PreCommit with non-blocking termination via participant election, (3) network partition causing split-brain (3PC only correct in synchronous crash-stop model). Includes ADRs explaining why 3PC is rarely used in production (Spanner Paxos commit, Saga, Outbox patterns are preferred).
Three-phase commit: non-blocking only under strong timing assumptions
Three-phase commit is an atomic-commit protocol for crash failures under synchronous timing/failure-detector assumptions. It separates canCommit, preCommit, and doCommit so no covered protocol state is adjacent to both abort and commit decisions. Participants durably record states and hold conflicting work while prepared/precommitted.
Its non-blocking claim is conditional: arbitrary delay or network partition destroys the knowledge needed for safe autonomous timeout decisions. Classic 3PC coordinates every participant rather than using a majority quorum. Paxos Commit is a different construction that uses consensus acceptors for transaction votes/decisions.
Prerequisites and model
- The covered model has bounded communication/processing delay, crash failures, and no arbitrary partition during recovery.
- Every participant durably records transaction id, vote, precommit, and terminal state before acknowledgement.
- Commit is valid only when all required participants vote yes and reach the committable protocol state.
- Duplicate phase messages are idempotent and stale epochs/coordinators are fenced.
Correctness claims and invariants
- 3PC-C1. 3PC inserts a precommit/committable state between unanimous prepare and final commit.
- 3PC-C2. Non-blocking progress depends on synchronous timing/failure assumptions and is not partition tolerance.
- 3PC-C3. Classic 3PC requires the transaction’s participants, not an R/W majority quorum.
- 3PC-C4. Participants persist state and keep conflicting resources locked through prepared/precommit recovery.
- 3PC-C5. Retries of phase messages are idempotent by transaction and coordinator epoch.
- 3PC-C6. Paxos Commit uses consensus to replicate commit votes/decision and has different quorum/progress assumptions.
What the scenarios prove
- 2PC blocking contrast (
two-pc-blocks-after-prepare): A 2PC participant prepared before coordinator crash cannot safely infer commit versus abort.
- 3PC canCommit vote (
can-commit-vote): All required participants durably vote yes before the coordinator advances.
- Precommit creates committable state (
precommit-state): Coordinator and participants persist precommit before final doCommit.
- Coordinator crash after precommit (
coordinator-crash-recovery): Under no-partition bounded-delay assumptions, a fenced recovery coordinator can finish from durable states.
- Partition breaks the non-blocking assumption (
network-partition): Separated participants cannot know whether unseen peers reached precommit, so autonomous timeout choices may diverge.
- Duplicate phase message is idempotent (
duplicate-phase-message): Retries use transaction id and coordinator epoch; terminal state cannot be reversed.
- Paxos Commit contrast (
paxos-commit-contrast): Consensus acceptors replicate participant votes/decision under a different progress model.
Failure, concurrency, and retry traps
- Calling 3PC partition tolerant overstates its model.
- A timeout is not proof that every participant is in the same phase.
- Releasing prepared locks before a terminal decision can violate atomicity.
- A new coordinator needs durable participant state and fencing, not just a health check.
- 3PC is not replicated-log consensus and has no inherent majority arithmetic.
Boundaries and non-guarantees
- Use 3PC only when its synchrony and failure assumptions are defensible.
- Across arbitrary WAN partitions, choose consensus-backed commit, explicit blocking/fail-closed behavior, or a saga/compensation model.
- Atomic commit does not provide isolation; concurrent transactions still need concurrency control.
- Paxos Commit is not a renamed 3PC phase.
Related material
[CONCEPT]consensus-overview [CONCEPT]cap-theorem [CONCEPT]byzantine-fault-toleranceTwo-phase commit is an explore diagram.
Saga orchestration and saga choreography model compensating workflows rather than atomic commit.