Choreography vs Orchestration in long running asynchronous processes
summary
Argues that a monolith is defined by coupled data schemas, not deployment, and that long-running async work should use an event store as authoritative state: commands go in, services emit domain events, aggregators build read models. Shows an onboarding example (email, GitHub, Slack, payroll, benefits, I‑9) to contrast choreography adds services without changing others vs orchestration centralizes process and eases rollbacks. Recommends mixing approaches: choreography for fire‑and‑forget tasks, orchestration where compensations and failure handling matter.
AI-written summary · about
chapters (11)
- 0:00Intro
- 1:29The enemy of change
- 5:53Autonomy
- 9:54Services
- 15:58Choreography
- 20:54Choreography Example
- 24:56Negatives of Choreography
- 26:48Choreography vs Orchestration
- 29:41Failure Conditions
- 30:31Big Processes
- 30:42The Ultimate Showdown
related talks
42mOrchestration vs Choreography, A Guide To Composing Your Monolith
32mBalancing Choreography & Orchestration
01h 13mOrchestration vs. Choreography in Microservices
25mFinding Harmony in Distributed Systems: Choreography vs Orchestration in Software Dev
59mOrchestration vs. Choreography: The good, the bad, and the trade-offs
46mChoreography vs Orchestration in serverless microservices
33mOrchestrate Your Choreography
50mChoreography vs Orchestration in Serverless Microservices