What is the CQRS Pattern and When Should You Use It?
Understand the CQRS pattern, how it splits reads from writes, and when it is worth the added architectural complexity.
Expected Interview Answer
CQRS (Command Query Responsibility Segregation) splits the logic and often the data models used for writing data (commands) from the logic and models used for reading data (queries), so a system can have a normalized write model optimized for consistency and a separately shaped, sometimes denormalized, read model optimized for fast querying.
In a traditional CRUD design, the same model and often the same table handle both reads and writes, which forces compromises: normalizing for safe writes makes some reads slow, needing joins across services. CQRS instead lets writes go through a command model that enforces business rules and updates the source of truth, while a separate read model — often a pre-joined, denormalized projection kept in sync via events — answers queries quickly without runtime joins. This is especially valuable in microservices, where it can replace expensive API composition: instead of composing data live from multiple services on every read, an event-driven process pre-builds a combined read model ahead of time.
- Read and write models can be scaled and optimized independently
- Read models can be pre-joined/denormalized, avoiding runtime joins across services
- Write side stays focused on validation and consistency, not query shape
- Enables event-driven population of purpose-built read stores
AI Mentor Explanation
Think of a cricket board that keeps a strict official register for recording every match result (the write side, with careful validation of scores and rules), but separately maintains a fast, pre-summarized leaderboard for fans to browse (the read side), rebuilt periodically from the official register rather than recalculated live on every page view. CQRS applies this exact split to software: commands go through a careful, validating write model, while queries hit a separately optimized, pre-built read model.
CQRS Splitting Write and Read Models
Command Model
- validates input
- writes to normalized store
- publishes event
Event
- OrderPlaced
- user_id
- total
Read Model
- pre-joined projection
- optimized for queries
Step-by-Step Explanation
Step 1
Send a command
A write request (e.g. PlaceOrder) goes through the command model, which validates business rules.
Step 2
Persist to the write store
The command model updates the normalized source-of-truth database and emits a domain event.
Step 3
Project into the read model
An event handler updates a separately maintained, denormalized read model to reflect the change.
Step 4
Serve queries from the read model
Read requests never touch the write model; they hit the pre-built projection directly for speed.
What Interviewer Expects
- Clear explanation of separating write (command) and read (query) responsibilities
- Understanding that read models are often denormalized and eventually consistent
- Awareness of when CQRS is worth the added complexity vs simple CRUD
- Ability to connect CQRS to event-driven architecture and read-model projections
Common Mistakes
- Claiming CQRS requires two separate physical databases in every case
- Ignoring that read models are typically eventually consistent, not instantly synced
- Recommending CQRS for simple CRUD apps where it adds unnecessary complexity
- Confusing CQRS with simple read replicas, which copy the same schema rather than reshaping it
Best Answer (HR Friendly)
“CQRS means splitting how you handle writes from how you handle reads. Writes go through a model that carefully validates and updates the source of truth, while reads are served from a separately optimized, often pre-joined view that is kept in sync via events. It is powerful for high-read, complex systems, but it's overkill for a simple CRUD app since it adds real complexity and usually some read lag.”
Code Example
-- Write side: normalized source of truth
CREATE TABLE Orders (
order_id INT PRIMARY KEY,
user_id INT NOT NULL,
total DECIMAL(10,2) NOT NULL,
status VARCHAR(20) NOT NULL
);
-- Command: insert enforces validation in application code first
INSERT INTO Orders (order_id, user_id, total, status)
VALUES (501, 42, 129.99, 'PLACED');
-- Read side: a separate, denormalized projection
-- populated asynchronously from the OrderPlaced event
CREATE TABLE OrderSummaryView (
order_id INT PRIMARY KEY,
customer_name VARCHAR(255),
total DECIMAL(10,2),
status VARCHAR(20)
);
-- Queries always hit the fast, pre-joined projection, not Orders:
SELECT * FROM OrderSummaryView WHERE order_id = 501;Follow-up Questions
- How does CQRS relate to event sourcing?
- How do you keep the read model in sync with the write model?
- What happens if a query hits the read model before the projection has updated?
- When would CQRS be overkill for a project?
MCQ Practice
1. What does CQRS primarily separate?
CQRS splits the logic and often the data model used for writes from the logic and model used for reads.
2. How is a CQRS read model typically kept up to date?
The write side emits domain events, and a handler updates the separately maintained read model, often asynchronously.
3. When is CQRS least appropriate?
For a simple CRUD application, CQRS adds architectural complexity (two models, eventual consistency) with little benefit.
Flash Cards
What does CQRS stand for? — Command Query Responsibility Segregation.
What is the write side of CQRS? — A command model that validates business rules and updates the source-of-truth data store.
What is the read side of CQRS? — A separately optimized, often denormalized model built specifically to answer queries fast.
How does the read model stay updated? — Typically via events published from the write side, making it eventually consistent.