Topic 13.10
13.11 — Distributed Transactions & 2PC
In one line
Two-phase commit's prepare/commit protocol — and why production prefers saga/outbox for everything except narrow windows.
Think of it like this
A wedding where the caterer, decorator, and band all need to confirm together before anyone charges your card — if even one of them can't make it, everyone's booking should be cancelled, not left half-confirmed.
Key ideas
- 01
2PC: coordinator asks all participants to PREPARE (can commit?); if all yes → COMMIT; else → ABORT. Atomic across nodes.
- 02
The catch: the coordinator is a single point of failure — a crash after prepare blocks everyone until recovery (indoubt transactions).
- 03
Timeouts in 2PC: participants hold resources while indoubt — the blocking commit problem.
- 04
Where 2PC is still used: distributed DB transactions (XA), exactly-once bridges in old middleware.
- 05
Why industry moved: sagas + outbox + idempotency give the same business outcome with best-effort + eventual consistency, no blocking.
- 06
Interview move: 'I avoid 2PC; for cross-service atomicity I use saga + outbox + idempotent steps' — full detail in phase-11.
Explain without notes
The coordinator dies between prepare-all and commit. Walk who is blocked and how recovery works.
Practice
Argue for saga over 2PC on a checkout: failure cases, latency, and the eventual-consistency acceptance.
Trade-offs
- ↔
2PC = atomic + blocking + fragile; saga = eventually consistent + resilient. The honest threshold matters per flow.
Completion checklist
I can explain prepare/commit, the coordinator failure mode, and why saga replaced it.