Topic 11.12
Distributed Transaction
In one line
One business operation spanning multiple services/DBs — where ACID dies and saga is born.
Think of it like this
Coordinating a group gift where five friends each need to contribute money for it to work. If even one friend backs out at the last moment, ideally everyone else's contribution should be returned too.
Key ideas
- 01
Local transactions end at the DB boundary; a 'distributed transaction' spans services — each with its own DB and its own commit.
- 02
2PC (two-phase commit): prepare all → commit all — correct but blocking and fragile (coordinator crash blocks resources).
- 03
The reality: 2PC rarely holds at scale; industry converges on sagas + idempotent steps + outbox.
- 04
Force the question out loud: 'which invariances MUST be atomic?' — usually fewer than you think.
- 05
Must-atomic examples: account debit (single DB) stays a local transaction; order+payment ACROSS services becomes a saga.
- 06
Interview: 'I keep atomicity inside one service's transaction and model cross-service flows as sagas'.
Java / Spring map
- →
@Transactional per service step + saga orchestrator; consider outbox for the step boundary (11.14).
Code & diagrams
2PC: everyone votes YES before anyone commits — but the coordinator itself becomes a single point of failure.
Explain without notes
Why can't 'place order' be one ACID transaction when orders live in three services?
Practice
Identify 3 cross-service flows in your design and label which are saga-eligible vs must-be-local.
Trade-offs
- ↔
Atomic = blocking + fragile; saga = eventually consistent + resilient. Correct by construction per flow is the job.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I know 2PC's failure mode and can argue why sagas replaced it in production.