Complexity is the Gotcha of Event-driven Architecture
summary
Event-driven systems deliver agility but inherit rapid, often-hidden complexity as services, brokers and channels scale; expect coupling, unclear domains and schema drift. Practical guardrails are: behavior-first event storming to map domain events before implementing, explicit event evolution strategies (backwards-compatible fields, parallel versions) and consumption rules (anti-corruption layers, conformist vs open host). Use tooling and specs like CloudEvents and AsyncAPI, and catalogue artifacts with Event Catalog (≈17,000 catalogs, ~50 contributors) to regain governance and trace who consumes what.
AI-written summary · about
chapters (11)
- 0:00Intro
- 2:32Agenda
- 3:53Potential of EDA
- 11:53Evolution architecture increases complexity
- 19:05Control complexity with guardrails
- 22:51Event Storming
- 25:52Event evolution strategy
- 31:09Complexity with event consumers
- 35:50Biggest gotcha of them all
- 42:09Summary
- 43:48Outro
related talks
55mNavigating complexity in event-driven architectures: A domain-driven approach
52mNavigating complexity in event-driven architectures: A domain-driven approach
31mThe Power of Event-Driven Systems without Burning your Hands or Budgets
42mDesign Principles for an Event-Driven Architecture
48mEvent-Driven Architecture – Benefits and Pitfalls
46mManaging Event Driven Architectures
48mEmpowering Architectural Evolution: Governing Event-Driven Solutions
54mSo You Want to Build An Event Driven System?
