Distributed transactions change data on more than one database node. Atomic commit gives all participants one outcome: commit or abort. Two-Phase Commit (2PC) is a common way to reach that outcome.
Two-Phase Commit
A coordinator manages the transaction. The database nodes taking part in the transaction are called participants. First, the coordinator asks whether each participant can commit. Then, based on how the participants vote, it sends everyone the same decision (either commit or abort).
Phase One: Prepare
The coordinator sends PREPARE to every participant, asking whether it can commit.
After PREPARE arrives each participant checks whether it can commit. A yes voter saves its prepared state and sends YES. A no voter rolls back its local transaction, releases its locks, and sends NO.
Prepare
Before PREPARE: local changes are staged. Both rows are locked.
Coordinator: Ready to send. Participant A: STAGED. row42 is locked. Participant B: STAGED. row17 is locked.
Phase Two: Commit or Abort
If everyone votes yes, the coordinator chooses COMMIT. If anyone votes no, it chooses ABORT. It can also abort if a vote does not arrive in time, as long as it has not already recorded commit. It records the decision in storage that survives a restart before sending it.
Each participant saves the outcome so it survives a restart, then commits its changes or rolls back its local transaction. It releases its locks and sends an acknowledgement.
Commit or Abort
Both participants are ready to send their votes.
Coordinator: Waiting for votes. Participant A: VOTED YES. Saved durably. row42 is locked. Participant B: VOTED YES. Saved durably. row17 is locked.
Guarantees and Costs
2PC coordinates participants on a single commit-or-abort decision.
That coordination has a cost:
- Votes and decisions require network round trips.
- The coordinator and participants must durably record information for recovery.
- The coordinator waits for every participant’s vote, so a slow participant can delay the decision.
- After voting yes, participants may hold locks while waiting for the decision, blocking other work.
Failures and Recovery
A participant that voted yes cannot safely abort just because it times out. The coordinator may already have recorded commit and told another participant. If the decision is unavailable, the prepared participant can remain blocked, holding locks while it waits.
Distributed SQL
Distributed SQL databases combine transaction coordination across shards with consensus replication within each shard. Systems such as Spanner, TiDB, YugabyteDB, and CockroachDB use these building blocks to keep transactions consistent across replicated data.
Replicated Shards
Each participant in the 2PC exchange can itself be a replicated shard. A shard leader waits for its local consensus group to durably prepare the change before voting YES. The coordinator then gathers one vote from each shard and records a single transaction decision.
One transaction, two replicated shards