Lost In Transaction
summary
Distributed systems force consistency outside the database: aggregates act as transaction boundaries, cross-aggregate ACID/XA is discouraged, and the practical solution uses compensating transactions (the Saga pattern) with retries and an idempotent transaction id on APIs. Long-running state and scheduled retries are needed, so a workflow engine like Camunda workflow engine persists process state, orchestrates steps, models compensations, and handles cleanup instead of two‑phase commit.
AI-written summary · about
chapters (11)
- 0:00Introduction to lost transactions
- 3:15Aggregate boundaries in DDD
- 7:36Why distributed transactions fail
- 10:01BASE principles explained
- 13:29Network unreliability in systems
- 16:43Idempotency in APIs
- 20:33Workflow engines for stateful tasks
- 23:24Saga pattern for consistency
- 26:57Choreography vs orchestration
- 30:28Graphical models for clarity
- 31:11Key takeaways summary
related talks
01h 01mLost in transaction Strategies to manage consistency in distributed systems
46mLost in transaction? Strategies to deal with (in-)consistency in distributed systems
31mLost in Transaction?
55mTackling transactions in Microservices applications
28mPractical Approaches To Scaling Distributed Transactions
30mData Consistency Patterns in Cloud Native Applications
47mBeing transactional in 2019 - what does this actually mean?
01h 38mBuilding Reliable Distributed Systems