Simplify Your Architecture: Events and Publishing
summary
Argues that using an in-memory event bus everywhere is harmful: without partition keys it yields choreography with no concurrency benefit, navigation problems, unbounded buffers and eventual OOM. Recommends calling another module’s facade (simple method calls) for same-application flows, keeping in-memory event buses only for true plugin scenarios (examples: Minecraft/Excel/TotalCmd), and using persistent brokers like Kafka/Jackdaw when durable buffering, partitioning or cross-service decoupling are needed. Also advises against premature generic libraries and prefers vertical slices over three-layer (lasagna) architectures.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 7:27Three-layer problems
- 16:53Architecture patterns in practice
- 27:48Events pros and cons
- 37:20Events for microservices
- 45:04Plugin architecture
- 50:20Generic vs specific
- 53:29Summary Q&A
related talks
26mMicroservice Architecture Based on Event Sourcing
46mEvent-Driven Microservices - not (just) about Events!
27mPatterns for Event-Driven APIs
31mThe Power of Event-Driven Systems without Burning your Hands or Budgets
47mEvent-Driven Microservices = Microservices Done Right
31mDemystifying Event-Driven Architectures
47mComplex event flows in distributed systems
53mArchitectural Simplicity through Events