Clean Microservices Communications with CQRS and Event Sourcing
summary
Claims that CQRS plus Event Sourcing yields unidirectional communication paths and much simpler service choreography, demonstrated by a Docker demo that actually builds an HTTP command API, an append‑only event store, MongoDB read models, and a change notifier using signal IO for live updates. Commands become persisted events, read models subscribe and emit commands for side effects (exchange rates, order confirmation), replayability and eventual consistency work in practice in the demo.
AI-written summary · about
chapters (13)
- 0:00Microservices communication challenges
- 1:02CQRS and event sourcing overview
- 3:13Service call chain complexity
- 8:13Command Query Responsibility Segregation
- 10:20Event sourcing principles and demo
- 13:33Live CQRS and event sourcing demo
- 18:53Read models and event data
- 21:41Unidirectional CQRS communication
- 24:14Read model side effects
- 27:25Command processor handling commands
- 28:30Eventual consistency in systems
- 30:17Real-time updates with notifications
- 34:31Summary and Q&A
related talks
17m7 Reasons why your microservices should use Event Sourcing & CQRS
40m7 Reasons why your microservices should use Event Sourcing & CQRS
56mDeveloping Event-driven Microservices w/Event Sourcing and CQRS
01h 25mBuilding microservices with event sourcing and CQRS
55m7 Reasons why your microservices should use Event Sourcing & CQRS
43mCommander: Better Distributed Applications through CQRS and Event Sourcing
46mMicroservices Data Patterns: CQRS & Event Sourcing
48mNodeJS Microservices + CQRS + Event Sourcing — Why Do I Do This?
