2-Phase Commit is a distributed transaction protocol used when a single transaction touches multiple database nodes (shards) and we need atomicity:
Either all shards commit or all shards roll back.
There are two phases:
Phase 1: Prepare (Voting Phase) Coordinator asks each shard: “Can you commit this transaction?”
Each shard:
- Executes transaction
- Locks affected rows
- Writes changes to log
- Replies: YES (ready) or NO (abort)
- No actual commit yet.
Phase 2: Commit / Abort
If ALL shards say YES:
- Coordinator sends COMMIT
- All shards finalize changes
If ANY shard says NO:
- Coordinator sends ROLLBACK
- All shards revert
Client → Coordinator → Shards (prepare) Coordinator → Shards (commit)
Rows stay locked during both phases.
Under heavy traffic: More contention Higher P99 latency Deadlock probability increases
If coordinator crashes after prepare: Shards remain in uncertain state Locks held System may stall
This is a known 2PC limitation.
Modern distributed SQL systems use:
- Raft-based consensus
- Optimistic concurrency
- Transaction pipelining
But internally, multi-shard transactions still resemble 2PC logic.