What is the CQRS pattern and when should you use it?
Understand the CQRS pattern, how command and query models are separated, its benefits, trade-offs, eventual consistency and when to use it in microservices.
Expected Interview Answer
CQRS (Command Query Responsibility Segregation) is a pattern that separates the model used to change data (commands) from the model used to read data (queries), so each side can be designed, scaled, and optimized independently.
In a traditional design, one model handles both reads and writes. CQRS splits them: commands mutate state and enforce business rules, while queries return data through read-optimized models, often backed by separate stores kept in sync via events. This lets you scale read and write workloads separately and shape read models per use case. It adds complexity and eventual consistency, so it fits high-scale or complex domains — not simple CRUD apps.
- Read and write sides scale independently
- Read models can be shaped and denormalized per query need
- Cleaner separation of business logic on the write side
- Pairs naturally with event sourcing and event-driven microservices
- Enables specialized data stores for reads vs writes
AI Mentor Explanation
Think of a match where the batting coach and the analytics desk are completely separate roles. The coach issues instructions that change what happens on the pitch, while the analytics desk only reads and reshapes data into dashboards for commentators. Neither interferes with the other, so each can be tuned for its own job — one for decisions, one for fast reporting.
Step-by-Step Explanation
Step 1
Split the model
Define a write model for commands that enforce rules and a read model for queries that return data.
Step 2
Model commands
Design commands as intent-carrying operations that validate business rules and mutate state.
Step 3
Model queries
Shape read models per use case, often denormalized for fast retrieval without joins.
Step 4
Sync the sides
Propagate changes from the write store to the read store, commonly via events or projections.
Step 5
Handle eventual consistency
Design the UI and clients to tolerate a small lag between a write and its appearance in reads.
What Interviewer Expects
- Clear definition of commands vs queries
- Why separating read and write models helps scaling
- Awareness that read and write stores can differ and sync via events
- Understanding of eventual consistency trade-offs
- Judgment about when CQRS is overkill versus justified
Common Mistakes
- Thinking CQRS always requires two separate databases
- Confusing CQRS with event sourcing (they are related but distinct)
- Applying CQRS to simple CRUD apps where it adds needless complexity
- Ignoring eventual consistency between the read and write sides
- Assuming CQRS is only about performance rather than model separation
Best Answer (HR Friendly)
“CQRS means using one part of the system for making changes and a separate part for reading data, so each can be tuned for its own job. It helps large or complex applications scale, but it adds complexity, so simple apps usually do not need it.”
Code Example
// Command side: changes state, enforces rules
async function handlePlaceOrder(cmd: PlaceOrder) {
const order = Order.create(cmd.items, cmd.customerId)
await writeStore.save(order)
await events.publish('OrderPlaced', order)
}
// Query side: reads an optimized, denormalized model
async function getOrderSummary(orderId: string) {
return readStore.findSummary(orderId) // no joins, fast
}Follow-up Questions
- How does CQRS relate to event sourcing?
- Does CQRS require two separate databases?
- How do you keep the read model in sync with the write model?
- How do you handle eventual consistency in the UI?
- When is CQRS an anti-pattern for a project?
MCQ Practice
1. What does CQRS separate?
CQRS splits the model that changes state from the model that reads state so each can be optimized independently.
2. Which is a common trade-off of CQRS?
When read and write stores are separate, reads can lag writes, giving eventual consistency.
3. When is CQRS usually a poor fit?
For simple CRUD, the extra models and consistency handling add complexity with little benefit.
Flash Cards
What does CQRS stand for? — Command Query Responsibility Segregation.
What is a command vs a query? — A command changes state and enforces rules; a query returns data without side effects.
Does CQRS need two databases? — No — it can share one store; separate read/write stores are an option, not a requirement.
Main trade-off? — Added complexity and eventual consistency between the read and write sides.
Continue Learning
Related Interview Questions
What is event sourcing and how does it relate to microservices?
hard
A service needs data owned by another service on almost every request. Do you call it, cache it, or copy it into a read model?
hard
What is CQRS (Command Query Responsibility Segregation)?
hard
What is the difference between a monolithic and a microservices architecture?
medium