CQRS
What is it?
CQRS is a pattern that separates the code that changes data (commands) from the code that reads data (queries), often using different models for each.
Explain like I'm 5
Why was it created?
In complex systems, reads and writes have very different needs. CQRS was adopted to optimize and scale them independently.
Where is it used?
- High-read or high-write systems
- Event-sourced applications
- Complex domains
- Independently scaling reads and writes
Why should developers care?
CQRS appears in high-scale and event-driven architectures, so it's relevant for senior backend and system design.
How does it work?
Commands (writes) and queries (reads) go through separate paths, often with separate data models. The write side enforces rules; the read side is shaped for fast queries, and the two are kept in sync — sometimes with a delay (eventual consistency).
Real-world example
An e-commerce system writes orders through a strict command model but serves product listings from a separate read model optimized for fast browsing.
Common use cases
- Scaling reads and writes separately
- Complex business rules on writes
- Optimized read views
- Pairing with event sourcing
Advantages
- Independent read/write scaling
- Optimized models for each side
- Cleaner complex domains
- Pairs well with event sourcing
Disadvantages
- Added complexity
- Eventual consistency to manage
- More code and infrastructure
- Overkill for simple apps
When should you use it?
When read and write workloads differ enough that separating them brings real benefits.
When should you avoid it?
For simple CRUD apps where one model is far simpler.
Alternatives
Related terms
Interview questions
Beginner
- What does CQRS separate?
- What's a command versus a query?
Intermediate
- Why use different models for reads and writes?
- How does eventual consistency come in?
Senior
- When is CQRS worth its complexity?
- How does CQRS pair with event sourcing?
Common misconceptions
- "CQRS requires event sourcing" — they pair well but are independent; you can use CQRS without it.
- "CQRS is always better for scale" — it adds complexity that simple apps don't need.
Fun facts
- CQRS stands for Command Query Responsibility Segregation.
- It builds on the older Command-Query Separation principle.
Timeline
- 2010s — CQRS popularized alongside event-driven design
Learning resources
Quick summary
CQRS separates write (command) and read (query) paths, often with distinct models, to optimize and scale each independently.
Cheat sheet
- Separate reads from writes
- Different models per side
- Scales each independently
- Adds complexity; not for simple CRUD