9 Fallacies of Event driven Architectures
summary
Nine concrete pitfalls are named and illustrated from three years building a production-grade marketplace: information overload from event-carried state transfer, teams becoming a message proxy instead of the true source, and costly replayability requirements when using AWS SNS + SQS (consider FIFO topics/queues). Concrete fixes include consumer-driven contract tests, a schema registry, designing idempotent receivers, avoiding command‑style events, and keeping routing logic out of the network (no SNS filter policy business logic). Expect hard operational work, not a silver bullet.
AI-written summary · about
chapters (12)
- 0:00Introduction and caveats
- 1:04What is event-driven architecture
- 4:35Basic event-driven patterns
- 7:19Fallacy one convenience over cause
- 11:11Fallacy two message proxy
- 16:51Fallacy three replay-ability hell
- 22:49Fallacy four decoupled yet synergized
- 35:18Fallacy five skewed events
- 38:27Fallacy six observability needed
- 42:18Fallacy seven smarts in network
- 44:03Fallacy eight testing isolation
- 47:16Conclusion and Q&A
related talks
29m9 Fallacies of Event Driven Architectures
30mHow Event Driven Architectures Go Wrong & How to Fix Them
47mTop 10 Event-Driven Architecture Pitfalls
41mGetting started with Event-Driven Architectures in 2023
48mEvent-Driven Architecture – Benefits and Pitfalls
47mComplexity is the Gotcha of Event-driven Architecture
44mComplexity is the Gotcha of Event-driven Architecture
44mThe Dark Side of Events