The Saga vs Two Phase Commit
A single transaction crossing several services cannot use one database transaction. Two patterns coordinate the work.
Two phase commit uses a coordinator. In the prepare phase it asks every participant to do the work and promise it can commit, holding locks. If all vote yes, the coordinator tells everyone to commit, otherwise it tells everyone to abort. The result is atomic, all or nothing. The cost is that participants hold locks across the whole protocol, and if the coordinator crashes after prepare, participants are blocked, unsure whether to commit. This blocking is why two phase commit is avoided in high availability systems.
Sagas drop atomicity for availability. A saga is a sequence of local transactions, each committed immediately. If a later step fails, the saga runs compensating transactions that undo the earlier steps, for example refunding a charge after a shipment fails. No locks are held across services and no coordinator can block everyone.
- Two phase commit gives strong atomicity but blocks on coordinator failure.
- Sagas stay available but expose intermediate states others can observe.
- Compensations must be written for every reversible step.
Sagas accept that a partial state is briefly visible, which two phase commit forbids. That tradeoff is why most microservice architectures choose sagas.
Key idea
Two phase commit gives atomic all or nothing across services but blocks on coordinator failure, while a saga stays available by committing local steps and undoing them with compensations.