Atomic Commit Protocol
Any protocol ensuring that several participants reach the same decision to commit or abort — and a problem provably unsolvable with certainty in an asynchronous system with failures.
The theoretical frame worth knowing, because it explains why the practical options are all compromises.
Atomic commit requires all correct participants to decide the same outcome. The FLP impossibility result shows that consensus cannot be guaranteed to terminate in an asynchronous system where even one process may fail — you cannot distinguish a crashed participant from a slow one, and waiting forever is not a decision.
Real protocols therefore trade one property away. Two-phase commit is safe but blocking: if the coordinator fails after prepare, participants cannot decide alone. Three-phase commit adds a pre-commit phase to become non-blocking, at the cost of extra latency and incorrect behaviour under network partitions. Consensus-backed commit, such as Paxos or Raft managing the commit decision, removes the single coordinator and is what modern distributed databases use — at the cost of the quorum round trips.
The architectural takeaway: when a design calls for atomic commit across services, that is a signal to question the boundary. The cheapest fix is usually to move the participants into one transactional resource, not to implement a better protocol.