Three-Phase Commit

Three-phase commit is an agreement protocol that decides whether a transaction touching several machines should be committed everywhere or aborted everywhere. There is one coordinator and a set of participants (think a database node per shard). The whole point is atomicity: either every participant applies the change or none of them does, even though they are separate processes on separate machines.

It exists because of a known weakness in two-phase commit (2PC). In 2PC a participant votes yes, then waits for the coordinator to tell it commit or abort. If the coordinator crashes after collecting votes but before sending the decision, that participant is stuck. It cannot commit on its own (another node might have voted no) and it cannot abort (others might already be committing). It holds its locks and blocks, sometimes until an operator intervenes.

3PC inserts an extra round so that no participant is ever in a state where it does not know how to recover. The cost is one more network round trip and a lot more complexity, which is why it is studied far more often than it is shipped.

Phase 1, canCommit: the coordinator asks every participant whether it can commit. Each participant checks constraints, locks rows, and replies yes or no. Nobody has written anything permanent yet. A single no, or a timeout, leads straight to a global abort.

Phase 2, preCommit: if all votes were yes, the coordinator sends preCommit. Each participant acknowledges and records that the decision is going to be commit. This is the new middle state that 2PC lacks. The key property is that the protocol only reaches preCommit when it already knows no participant voted no, so a commit is now safe.

Phase 3, doCommit: the coordinator sends doCommit and participants finalize and release locks. The recovery rule is what makes 3PC non-blocking: if the coordinator dies, a participant that has reached preCommit can time out and commit anyway, because preCommit guarantees everyone agreed. A participant still in the canCommit state will time out and abort. Either way it acts without waiting forever.

The catch is the assumption behind that recovery rule. 3PC is non-blocking only under a synchronous model with reliable failure detection and no network partitions. In a real asynchronous network a partition can split nodes that timed out and committed from nodes that timed out and aborted, producing an inconsistent result. That is the practical reason it is rarely deployed.

Use a strong commit protocol like this only when you genuinely need atomic commit across nodes and cannot tolerate partial writes. For most application workloads you do not, because the latency cost of multiple synchronous round trips and held locks hurts throughput badly under load.

In practice teams reach for one of three alternatives. They keep 2PC and accept its blocking risk, often with a transaction manager and quick coordinator failover. They replace distributed atomic commit with a saga: a sequence of local transactions plus compensating actions that undo earlier steps if a later one fails, trading strict atomicity for availability and eventual consistency. Or they push the agreement problem down to a consensus protocol like Paxos or Raft, which gives a correct fault-tolerant decision and is what modern systems actually build on.

The honest summary is that 3PC solved the wrong half of the problem. It removed blocking but assumed away network partitions, and partitions are the failure that distributed systems must survive. Consensus-based commit (for example a commit protocol layered on Raft) gives you a fault tolerant decision without the false safety, so 3PC mostly survives as a teaching tool that explains why consensus is needed.

Imagine a banking transfer of 100 dollars where the source account lives on shard A and the destination on shard B. The coordinator runs canCommit: shard A checks the balance and locks the row, shard B locks the destination row, both reply yes. So far nothing is final and the money has not moved.

The coordinator sends preCommit and both shards acknowledge. Now suppose the coordinator crashes right here. Under 2PC both shards would sit on their locks indefinitely, freezing both accounts. Under 3PC each shard times out, sees that it reached preCommit, and independently commits the transfer, then releases its locks. The transfer completes without an operator.

The failure 3PC cannot handle is a partition during phase 3. If a network split leaves shard A able to commit while shard B is isolated and times out into abort, you end up with money debited from A but never credited to B. That single scenario is why systems such as Google Spanner and CockroachDB use Paxos or Raft for the commit decision instead of plain 3PC.