Two-phase commit (2PC): an interactive sequence diagram

Two-phase commit (2PC) makes one transaction commit on several databases together, or on none of them. A coordinator first asks every participant to prepare, to make its changes durable and promise to commit, and only if every one votes yes does it tell them all to commit. The price is that a participant that has voted yes must wait for the decision with its locks held, and if the coordinator fails at the wrong moment, it waits until the coordinator comes back.

The playground runs one order across three databases: orders, payments and stock. Pick what goes wrong and read the sequence diagram from top to bottom: arrows are messages, and the bar beside each line shows what that database is doing.

How two-phase commit works

1. Execute: each participant does its part of the transaction and takes its locks, without committing.
2. Prepare: the coordinator sends PREPARE. Each participant writes its changes and a prepare record to its log, durably, then votes YES, or votes NO and rolls back.
3. Decide: if every vote is YES the coordinator writes COMMIT to its own log; one NO, or a vote that never comes, means ABORT. Writing the decision down is the moment the transaction commits.
4. Complete: the coordinator sends the decision; each participant commits or rolls back, releases its locks and acknowledges. Once all have acknowledged, the coordinator can forget the transaction.

Why two-phase commit blocks

A participant that votes YES gives up the right to decide. It cannot commit on its own, because another participant may have voted NO, and it cannot abort, because the coordinator may already have logged COMMIT and told someone else. Until it hears the decision it is in doubt, and it keeps its locks, so every other transaction that needs those rows waits too.

Normally that lasts about a round trip, 30 to 40 ms in the first preset. But if the coordinator crashes after the votes, the participants are stuck for as long as it is down: 3 seconds or 30 seconds in the playground, hours if it needs an operator. A crash after deciding is subtler: one database has committed and the others are holding their locks waiting to find out. Three-phase commit tries to remove the blocking with timeouts, but it is only safe if message delays are bounded, which real networks do not promise. Systems that need 2PC to be available instead make the coordinator itself fault tolerant: Google Spanner runs each participant and the coordinator as a Paxos-replicated group, so a crashed machine is replaced rather than waited for.

The cost when nothing fails

• Latency: two round trips to every participant, plus a durable log write on each and on the coordinator.
• Contention: locks are held across both round trips, so hot rows serialise transactions for longer.
• Availability: every participant must be up to commit; with five participants each up 99.9% of the time, a transaction that needs all of them can commit about 99.5% of the time.

Two-phase commit vs sagas

Across microservices, and across third parties such as a payment provider that will never take part in your protocol, sagas with idempotent steps and an outbox are the usual answer. Two-phase commit lives inside systems that control every participant: XA transactions across databases, PostgreSQL’s PREPARE TRANSACTION, distributed SQL databases such as Spanner and CockroachDB, and Kafka’s transactions, whose coordinator writes commit markers to every partition involved.

Two-phase commit in SQL

-- PostgreSQL: each participant prepares, and the coordinator finishes it later
BEGIN;
UPDATE accounts SET balance = balance - 40 WHERE id = 7;
PREPARE TRANSACTION 'order-1842';      -- phase 1: durable, locks kept, vote YES

-- ... the coordinator collects every vote and logs its decision ...

COMMIT PREPARED 'order-1842';          -- phase 2, if every vote was YES
-- or: ROLLBACK PREPARED 'order-1842';

-- after a crash, prepared transactions are still there, still holding locks:
SELECT gid, prepared FROM pg_prepared_xacts;

In a system design interview

When a transaction spans services, name the choice: “Placing an order touches the orders, payments and inventory services, each with its own database. I would not use two-phase commit across them: it holds locks across the network and blocks if the coordinator fails, and the payment provider cannot take part anyway. A saga reserves stock, charges the card and confirms the order, each step idempotent, and if the charge fails it releases the reservation.” If the data lives in one distributed database, say that it runs a form of two-phase commit for you internally, and what that costs in latency.

Read the guide to distributed transactions and idempotency, see Raft for how a coordinator can be made fault tolerant, or watch a strong candidate design a payment system.

Questions people ask