Event Driven Architecture – Enabling Microservices
summary
Explains a concrete migration path: add an append-only event store (Kinesis / Azure Event Hub / Kafka) and initially write to an event store first alongside the DB with a dual commit, then flip the event store to be the system of record. Uses Docker/Kubernetes for orchestration, claims users see responses faster and crashes drop ~75%, eventual consistency is seconds, Kafka keeps throughput steady day‑1 vs day‑1000, Target keeps ~6 years of events, Gilt runs thousands of services at ~70M visitors, and teams can replay historic traffic to test capacity.
AI-written summary · about
chapters (19)
- 0:00Introduction to EDA and microservices
- 1:50What is event-driven architecture
- 6:02Messages vs events distinction
- 7:27Retail system example walkthrough
- 9:56Problems with monolithic architecture
- 12:20Introducing event store for migration
- 16:34Breaking monolith into microservices
- 20:11Synchronous vs asynchronous processing
- 23:16Event store reliability and failure handling
- 27:37Challenges and misconceptions of EDA
- 30:58Eventual consistency explained
- 33:26Docker and Kubernetes in microservices
- 37:46Advantages of event-driven architecture
- 42:03Replaying events for testing and debugging
- 45:24Business benefits of EDA
- 50:39Domain decoupling and scalability
- 52:47Practical challenges with microservices
- 55:11Technology options for event streaming
- 1:01:12Performance and scalability of event stores
related talks
45mCommon quandaries implementing your first Event Driven Architecture
25mData-Driven Migration from Monoliths to Event-Driven Microservices
47mEvent-Driven Microservices = Microservices Done Right
48mEvent-Driven Architecture – Benefits and Pitfalls
31mDemystifying Event-Driven Architectures
41mGetting started with Event-Driven Architectures in 2023
39mEvent Driven Architecture: From Ideation to Production
42mCreating event-driven microservices: the why, how and what