Distributed Commit Protocols
Distributed commit protocols coordinate one commit-or-abort decision across transactional participants.
Jul 11, 2026
A distributed commit protocol coordinates participants that each provide a durable prepare operation. It aims to make every participant commit or every participant abort one distributed transaction.
This is different from consensus: commit participants may hold application resources, and a valid outcome depends on their votes as well as coordinator state.
Two-Phase Commit
Two-phase commit (2PC) has two main phases:
- Prepare: the coordinator asks each participant to prepare. A participant that votes yes durably records enough state to commit later and keeps required resources reserved.
- Decision: if every participant votes yes, the coordinator durably records commit; otherwise it records abort. It repeatedly communicates that decision until participants resolve.
After voting yes, a participant cannot unilaterally abort without risking disagreement. If it cannot learn the coordinator’s decision, it can remain blocked while holding locks or other resources.
The coordinator must recover its durable decision log after a crash. Treating it only as an in-memory single point of failure misses the protocol’s recovery model, but losing or delaying its decision still affects availability.
Prepared transactions should be short-lived and monitored. PostgreSQL, for example, warns that abandoned prepared transactions retain locks and interfere with vacuum.
Three-Phase Commit
Three-phase commit (3PC) adds a pre-commit phase so participants have more information before the final decision. Its non-blocking argument depends on assumptions such as bounded communication delay and limited failure patterns.
Under arbitrary network partitions or asynchronous timing, participants cannot reliably distinguish a failed peer from an isolated one. 3PC therefore does not generally eliminate blocking while preserving one consistent outcome.
When To Use
Use distributed commit only when:
- every participant supports a compatible prepare/commit protocol;
- temporary resource blocking is acceptable;
- a transaction manager durably tracks decisions and recovery;
- operators can detect and resolve old prepared transactions.
When business steps cannot remain prepared, Saga Pattern may fit better, but it provides different semantics rather than a drop-in replacement.