7 Reasons why your microservices should use Event Sourcing & CQRS
summary
Argues seven concrete reasons to choose Event Sourcing + CQRS for microservices: replace CRUD with an append-only event store (keyed by entity ID + sequence), separate command/write path from read/projection path so reads use multiple optimized stores (Postgres, Elasticsearch, graph), and use a pull-based reader to reliably push events to read DBs or Kafka to avoid losing events during failures. Claims this eases schema ownership, removes cross-service DB coupling by publishing customer events for local views, improves write concurrency for spikes (eg. Black Friday), and relies on at-least-once delivery plus dedupe; it works but adds operational complexity.
AI-written summary · about
chapters (13)
- 0:00Introduction and background
- 1:26Monoliths vs microservices
- 3:12Microservice characteristics
- 7:06Event Sourcing and CQRS basics
- 14:54Reason 1: Design phase benefits
- 17:00Reason 2: Reduced service coupling
- 23:52Reason 3: Event propagation patterns
- 30:14Reason 4: Read vs write bottlenecks
- 33:04Reason 5: Concurrency barriers
- 36:36Reason 6: Simplified messaging
- 42:37Reason 7: Eliminate service coupling
- 45:23Reason 8: Graduate from IT governance
- 49:14Q&A and closing remarks
related talks
40m7 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
51mMicroservices Data Patterns: CQRS & Event Sourcing
46mMicroservices Data Patterns: CQRS & Event Sourcing
47mFrom C to Q, One Event at a Time: Event Sourcing in Pictures
56mDeveloping Event-driven Microservices w/Event Sourcing and CQRS
51mCQRS + ES = CRUD, QED