Two-phase commit (2PC)
A protocol for a transaction spanning multiple resources/nodes: a coordinator asks all to prepare, then to commit or abort. Gives atomicity across shards/services but is slow and blocks if the coordinator or a participant fails. The classic distributed-transaction protocol.
- Atomic writes across a small number of resources.
- When correctness across resources is mandatory.
- High-throughput or large-fan-out transactions.
- Long-running transactions (use a saga).
Definition
2PC has a prepare phase (coordinator asks participants to lock and promise to commit) and a commit phase (coordinator tells them to commit or abort). If any participant votes no, all abort. Once prepared, a participant must be able to commit.
Why it exists
A transaction touching multiple databases must be atomic across them. 2PC coordinates so all commit or none do, extending ACID across resources.
How it works
Coordinator sends PREPARE; participants lock and reply YES/NO. If all YES, coordinator sends COMMIT; else ABORT. Participants acknowledge. If the coordinator fails after prepare, participants block holding locks until it recovers (the blocking problem).
Scaling limits
Blocking: a failed coordinator stalls participants holding locks. Slow (multiple round trips). A participant failure can stall the whole transaction. Doesn't scale to many participants or high throughput.
Cost shape
Latency from multiple round trips + locks held during the protocol. Blow-ups: held locks causing contention and blocking on coordinator failure.
Alternatives
- Saga — Non-blocking but only eventually consistent with compensations.
- Raft-replicated log — Strong consistency within one system, not cross-resource.
Failure modes
- Coordinator failure blocking participants.
- Long-held locks.
- Participant failure stalling the transaction.