7 Reasons why your microservices should use Event Sourcing & CQRS
summary
Seven concrete reasons: using an event store means commands append immutable events (inserts only) so writes are extremely fast and replayable; read models are separate so reads can be optimized while accepting eventual consistency; messaging resilience uses a pull/offset pattern with Kafka and delivers at least once semantics requiring idempotent consumers; this raises the concurrency and traffic ceiling (tests show order-of-magnitude faster writes), lets services own replicated customer views, and removes cross-team DB governance bottlenecks.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 1:43Modernizations journey
- 3:20Microservices characteristics
- 6:51Break up the data
- 7:50What is Event Sourcing
- 12:10Event Modeling
- 14:20Reduce Service Coupling
- 18:22CQRS Pattern
- 20:32Read vs Write Performance
- 22:06Elevate the concurrency barrier
- 24:42Simplify messaging
- 26:52Dealing with messaging
- 29:11Speed of light
- 30:27Pull pattern
- 33:29Governance
- 35:41Conclusion
- 36:56Stateless vs Stateful
related talks
55m7 Reasons why your microservices should use Event Sourcing & CQRS
17m7 Reasons why your microservices should use Event Sourcing & CQRS
01h 25mBuilding microservices with event sourcing and CQRS
46mMicroservices Data Patterns: CQRS & Event Sourcing
51mMicroservices Data Patterns: CQRS & Event Sourcing
56mDeveloping Event-driven Microservices w/Event Sourcing and CQRS
40mClean Microservices Communications with CQRS and Event Sourcing
47mFrom C to Q, One Event at a Time: Event Sourcing in Pictures