Back to Catalog
Microservices
Data Management
CQRS
Split reads and writes into separate models — optimize each independently.
Intent & Description
Real-world Use Case
Order dashboard needs orders + customer names + product titles. CQRS maintains an “OrderSummaryView” table that joins all three, updated via events. Dashboard queries one table, fast.
Source
📌 TL;DR
CQRS = different DB for reading vs writing. Reads are fast and denormalized, writes stay clean. Price: eventual consistency.
Advantages
- Queries are blazing fast — read model is shaped exactly for the query
- Read and write sides scale independently
- Solves cross-service query problem cleanly
- Works great with Event Sourcing
Disadvantages
- Eventual consistency — read model lags writes by milliseconds to seconds
- More moving parts — event consumers, view DBs, sync lag monitoring
- Schema changes need coordinated updates on both sides
- Debugging is harder when read/write paths diverge