CQRS (Command Query Responsibility Segregation)
Separating read and write operations for scalability and flexibility in distributed systems.
3 min read2026-03-22mediumcqrspatternsarchitecture
What is CQRS?
CQRS stands for Command Query Responsibility Segregation. It separates the read (Query) and write (Command) sides of an application into different models.
Core Principle
"A method should either change the state of an object or return a result, but not both." — Bertrand Meyer (Command-Query Separation)
Traditional vs CQRS
Traditional (CRUD)
Client → Single Model → Single Database
(Read + Write)
CQRS
Client ─── Write ──→ Command Model ──→ Write DB
│
└── Read ──→ Query Model ──→ Read DB
When to Use CQRS
Good Fit
- Read and write workloads differ significantly (e.g., 90% reads)
- You need different data models for reading vs writing
- You need to scale reads and writes independently
- Complex business logic on writes, simple queries on reads
Bad Fit
- Simple CRUD applications
- Small teams with limited resources
- When eventual consistency is not acceptable
Implementation Example
CQRS + Event Sourcing
CQRS is often combined with Event Sourcing, where the write side stores events and the read side builds materialized views from those events.
| Component | Role |
|---|---|
| Command | Validates and produces events |
| Event Store | Append-only log of all events |
| Event Handler | Builds read models from events |
| Read Model | Denormalized, optimized for queries |
Interview Hint
In system design interviews, mention CQRS when the interviewer asks about scaling a read-heavy system. It shows you understand that reads and writes can be optimized independently.
Trade-offs
| Advantage | Disadvantage |
|---|---|
| Independent scaling of reads/writes | Increased complexity |
| Optimized data models per side | Eventual consistency between models |
| Better separation of concerns | More infrastructure to manage |
| Flexible for complex domains | Overkill for simple apps |