The Power of Event-Driven Systems without Burning your Hands or Budgets
summary
Advocates claim events make systems simpler but the concrete warnings are specific: event sourcing captures the full history so current state is derived, while emitting events as a CDC side effect breaks correctness and observability; messaging splits into three types — commands and queries plus events — and choosing the wrong one creates awkward coupling. Practical concerns include delivery guarantees like at-least-once vs at-most-once, schema evolution, and replaying millions of events; start with a modular monolith and use tools such as Axon Framework when discipline and boundaries are clear.
AI-written summary · about
chapters (15)
- 0:00Intro
- 1:14Once upon a time...
- 3:17Microservices to the rescue!
- 3:54Universal microservices architecture
- 7:03Events to the rescue!
- 8:53Event-driven microservices architecture
- 9:51The promise
- 12:04Events as side-effect
- 14:07Events & stored state
- 16:17Event sourcing
- 17:15Awkward coupling
- 19:22Microservices messaging
- 21:47Location transparency
- 24:14Technical complexity
- 28:13Outro
related talks
46mEvent-Driven Microservices - not (just) about Events!
48mEvent-Driven Architecture – Benefits and Pitfalls
44mEvent-Driven Microservices, the Sense, the Non-sense and a Way Forward
44mComplexity is the Gotcha of Event-driven Architecture
54mDemystifying ‘Event’ Related Software Concepts and Methodologies
31mDemystifying Event-Driven Architectures
52mSo You Want to Build An Event Driven System?
01h 12mDemystifying "event-based" software concepts and methodologies