Distributed Transactions
This map connects alternatives for coordinating changes that do not share a local commit. The starting point is the business outcome, the intermediate states it accepts, and the recovery it can sustain.
Reading path
| Document | Starting question |
|---|---|
| atomic-commit | What does it mean for every participant to commit or abort? |
| two-phase-commit | How is a decision prepared and preserved across transactional resources? |
| saga-pattern | How can a sequence of local commits be completed or compensated? |
| try-confirm-cancel | Can the domain reserve resources and then confirm or release them? |
atomic-commit defines the problem; two-phase-commit presents one protocol. saga-pattern and try-confirm-cancel offer different business contracts, not equivalent implementations of a global rollback.
Decision questions
- Can the boundary be simplified with a local transaction?
- Is partial execution unacceptable, or can it be corrected after becoming visible?
- Can each resource prepare a transaction, reserve capacity, or compensate an effect?
- How long may a decision wait, and who resolves it after a failure?
- Does a timeout mean rejection, uncertainty, or expiration of a commitment?
There is no universal ranking of better and worse approaches. The choice depends on guarantees, intermediate states, recovery, and business capabilities.