What is CQRS (Command Query Responsibility Segregation)?
Why Interviewers Ask This
This question targets practical, hands-on experience with System Design. Interviewers want to see if you've worked with these concepts in real projects, not just read about them. Strong answers include concrete examples.
Answer
CQRS separates the model for reading data (queries) from the model for writing data (commands). Instead of one model that handles both, CQRS uses separate models optimized for each concern. Command side: handles write operations (Create, Update, Delete commands); validates business rules; updates the write database; publishes events about what changed. The write model is optimized for consistency and business logic. Query side: handles read operations; maintains one or more denormalized, read-optimized projections/views; updated asynchronously from command-side events. Multiple read models can serve different query patterns (a "recent orders" view and a "order analytics" view from the same write model). Benefits: (1) Each model can be independently scaled and optimized; (2) Read models can be highly denormalized for query performance without affecting write model; (3) Multiple read models for different access patterns; (4) Clear separation of concerns; (5) Simpler write model (focused on invariants, not queries). Challenges: eventual consistency — read models lag behind writes; more complexity (two models, synchronization infrastructure); not every system needs this complexity. When to use: high read:write ratio, complex query requirements, different scaling needs for reads/writes, event-driven architecture. Simpler CQRS: just use separate read and write methods/services without separate databases — already provides separation of concerns. Full CQRS with separate databases adds complexity but maximum performance separation.
Pro Tip
Back up your answer with a specific project or situation. Saying 'In my last System Design project, I used this when...' immediately makes your answer more credible and memorable.