Balancing Choreography & Orchestration
summary
Argues that choreography is event-driven communication (event notifications) and orchestration is command-driven communication (intent/commands), warns that long event chains produce a pinball machine architecture with hidden flows, versioning pain and no clear accountability, and shows stateful orchestration implemented via a workflow engine to manage long waits, retries and visibility. Recommends choosing per communication link: use events for decoupled reactions, commands where responsibility, ordering or legal guarantees require control, and mix both.
AI-written summary · about
chapters (15)
- 0:00Intro
- 1:23Orchestration vs choreography
- 3:47Example
- 4:25Synchronous call chains
- 5:46Asynchronous call chains
- 6:22Choreography or orchestration?
- 7:49Event-driven
- 9:31P2P event chains
- 16:10Decide about responsibility
- 19:56Stateful orchestration
- 22:15Glue code e.g. Java
- 23:07Using a workflow engine
- 24:20Challenge: Command vs event
- 31:04Your IT architecture
- 31:44Summary
related talks
59mOrchestration vs. Choreography: The good, the bad, and the trade-offs
33mOrchestrate Your Choreography
42mOrchestration vs Choreography, A Guide To Composing Your Monolith
38mChoreography vs Orchestration in long running asynchronous processes
01h 01mOrchestration vs. Choreography: The good, the bad, and the trade-offs
25mFinding Harmony in Distributed Systems: Choreography vs Orchestration in Software Dev
01h 13mOrchestration vs. Choreography in Microservices
47mComplex event flows in distributed systems