Book Overflow Never use this pattern with microservices! - Software Architecture: The Hard Parts
Apr 27, 2026
They debate orchestration versus choreography for microservices with real-world analogies. Saga patterns and the risks of asynchronous, atomic choreographies get a close look. Trade-off thinking, fitness functions, and ADRs for enforcing architecture are explored. They trace data platforms from warehouses to data mesh and critique overstated LLM productivity claims.
AI Snips
Chapters
Books
Transcript
Episode notes
Choose Orchestration When State Management Must Be Simple
- Prefer orchestration when you need simpler state management and easier rollbacks; prefer choreography when central coordination is impractical.
- Weigh team dynamics and single-point-of-failure risk: orchestrator teams become gatekeepers and must handle combined system scale.
Sagas Map TradeOffs In Three Dimensions
- Saga patterns sit on three axes: sync vs async, atomic vs eventual, and orchestration vs choreography, producing named saga types.
- The worst combo is the 'horror story' (async + atomic + choreographed) because it demands atomicity without central coordination.
Avoid Async Choreography With Atomic Transactions
- Avoid designing systems that are asynchronous, choreographed, and require atomic transactions; instead accept eventual consistency.
- The authors recommend the anthology pattern (async + choreographed + eventual) over attempting holistic transactions in that context.
