# CQRS

> Split reads and writes into separate models — optimize each independently.

- **Category**: Microservices
- **Subcategory**: Data Management
- **Canonical URL**: https://designpattern.fyi/patterns/cqrs/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
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.





## Trade-offs


### 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




### Considerations & Drawbacks

- 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







---
**Reference**: [Original Source](https://microservices.io/patterns/data/cqrs.html)