Two-Phase Commit

When one transaction touches data on more than one machine, you have a problem: each machine can commit or roll back on its own, but you need them to act as a unit. If the order service saves a row but the inventory service crashes before it saves, you have charged a customer for stock you never reserved. Two-Phase Commit is the classic protocol that prevents that split outcome.

There are two roles. A coordinator (sometimes called the transaction manager) drives the protocol. The participants (the resource managers, usually databases) each hold one piece of the transaction. The whole point is atomicity across all of them: either every participant commits, or every participant aborts, and nobody is allowed to be left half done.

2PC gives you atomic commit but it is not the same as consensus protocols like Paxos or Raft. Those keep working when a node fails. 2PC, in its basic form, can get stuck if the coordinator dies at the wrong moment, which is its biggest weakness.

Phase one is prepare. The coordinator sends a PREPARE message to every participant. Each participant does all the work it can without finalizing: it writes the changes to its log, takes locks, and makes sure it could commit if asked. It then writes a prepare record to durable storage and replies YES (also called a vote to commit) or NO. Once a participant has voted YES it is in a prepared state and has promised it can commit even if it crashes and restarts, so it must keep its locks held.

Phase two is the decision. If every participant voted YES, the coordinator writes a commit record to its own log, then sends COMMIT to everyone. If even one voted NO, or one timed out, the coordinator writes an abort record and sends ABORT. Each participant carries out the order, releases its locks, and sends back an acknowledgement. The coordinator's log write is the single point where the outcome becomes final.

The danger window is the prepared state. A participant that has voted YES cannot decide on its own. If the coordinator crashes after collecting votes but before sending the decision, the participant is blocked. It holds its locks and waits, because committing or aborting unilaterally could disagree with what the coordinator already logged. This is why 2PC is called a blocking protocol.

Use 2PC when you genuinely need atomic commit across separate systems and the systems are usually healthy, low latency, and within your control. Distributed SQL databases, the XA standard used by Java application servers and message brokers, and some transactional file systems all rely on it. It is correct and well understood, which is why it has survived for decades.

The costs are real. Every commit needs at least two network round trips plus several forced disk writes, so latency goes up and throughput goes down. Locks are held from prepare until the decision arrives, so a slow participant stalls everyone and reduces concurrency. And the blocking problem means a coordinator failure can freeze a transaction until an operator or a recovery process steps in. Three-Phase Commit adds an extra round to reduce blocking, but it assumes bounded network delays and is rarely used in practice.

For this reason many modern systems avoid 2PC across service boundaries. Instead they use the Saga pattern, which breaks the work into local transactions with compensating actions that undo earlier steps, trading strict atomicity for availability. A good rule: keep 2PC inside one tightly coupled cluster, and reach for Sagas when services are independent and failures are common.

Imagine a bank transfer of 100 dollars where the source account lives in shard A and the destination in shard B. The coordinator sends PREPARE to both shards. Shard A checks the balance, deducts 100 in its log, locks the row, and votes YES. Shard B logs the 100 credit, locks its row, and votes YES.

Both votes are in, so the coordinator writes COMMIT to its log and tells both shards to commit. Money leaves A and lands in B atomically. If instead shard A had reported insufficient funds and voted NO, the coordinator would have written ABORT, and shard B would have rolled back its prepared credit so no money appears out of nowhere.

Now suppose the coordinator crashes right after both shards voted YES but before it sent the decision. Both shards sit in the prepared state with rows locked, unable to commit or abort, until the coordinator restarts, reads its log, sees no commit record, and replays the protocol to a safe conclusion. That stuck interval is exactly the blocking behavior 2PC is famous for.