5.1. Distributed Transactions
A transaction that spans services cannot rely on a single database’s ACID guarantees, so you must rebuild atomicity from parts that can each fail independently. Two-phase commit gives you atomicity but blocks when the coordinator dies; sagas give you availability but force you to design compensating actions for every step. This chapter covers that trade-off in depth, along with the outbox pattern that solves the deceptively hard problem of writing to a database and publishing a message atomically.
Topics Covered
Section titled “Topics Covered”- 5.1.1. ACID vs. BASE: Guarantees and Trade-offs: Contrasts ACID’s strict guarantees with BASE’s availability-first relaxation and when each is appropriate.
- 5.1.2. Two-Phase Commit (2PC): Blocking Nature and Risks: Explains two-phase commit, its atomicity guarantee, and the blocking that occurs when the coordinator dies.
- 5.1.3. Three-Phase Commit (3PC): Reducing Blockage: Covers 3PC as an academic attempt to reduce blocking, and precisely how a partition still defeats it.
- 5.1.4. The SAGA Pattern: Choreography vs. Orchestration: Explains the saga pattern and the choreography-versus-orchestration choice for coordinating multi-step transactions.
- 5.1.5. Compensating Transactions: Covers compensating transactions, the semantic undo actions that roll back a saga when a step fails.
- 5.1.6. The Outbox Pattern: Atomic DB Write + Message Publishing: Explains the outbox pattern that atomically writes to a database and publishes a message, plus the inbox counterpart.