Events, Workflows, Sagas? Keep Your Event-driven Architecture Sane.
summary
A common order example shows an order requiring inventory and payment checks; implementing that as a centralized workflow or Saga (using Temporal, Camunda, Google Workflows) forces a stateful coordinator that persists progress, handles timeouts, and often needs Paxos/raft-style distribution, creating complexity and a distributed monolith. Instead the talk argues to break processes into micro-workflows, move the relevant data to where decisions run (bring data to the behavior), treat events as facts not commands, and separate observability from control so services remain autonomous and simpler.
AI-written summary · about
chapters (21)
- 0:00Introduction
- 1:24Event-driven architecture basics
- 3:53Workflow challenges in microservices
- 7:23Saga pattern explained
- 8:05Why workflows and sagas suck
- 13:59Problem with workflows
- 16:05Events vs commands in architecture
- 20:36Event-driven alternative design
- 22:23Control vs observability
- 23:26Timeouts and error handling
- 26:16Responsibility in event-driven systems
- 27:44Complex workflows revisited
- 28:46Mindset shift for event-driven
- 30:12Unix philosophy analogy
- 31:35Complexity vs simplicity
- 32:58SAFe vs agile critique
- 33:41Orchestration vs choreography
- 34:24When workflows are useful
- 35:50Common counterarguments
- 37:34First principles approach
- 38:18Summary and conclusion
related talks
56mEvents on the outside, on the inside and at the core
58mElements of Distributed Architectures
47mComplexity is the Gotcha of Event-driven Architecture
30mHow Event Driven Architectures Go Wrong & How to Fix Them
42mOrchestration vs Choreography, A Guide To Composing Your Monolith
48m9 Fallacies of Event driven Architectures
52mEvent Driven Workflows
15mEvents are the Wrong Abstraction for Your AI Agents