CQRS (Command Query Responsibility Segregation) separates the model used to update data from the model used to read it. The write side focuses on business rules; the read side organizes information for display or lookup.
For example, booking a cinema ticket requires checking seat availability. Listing tickets needs the film name, showtime, and seat location. These tasks involve the same data but require different processing.
Both models can live in the same application and share a database. CQRS does not require two databases, a queue, or Event Sourcing.
When a customer selects a seat, the request goes to the write side. The system checks and saves the booking; a transaction with suitable data constraints must prevent two customers from booking the same seat for one showing. Once the write succeeds, the customer receives confirmation.
When the customer opens “My tickets,” the read side returns a list with film names, showtimes, and seats. Its presentation can change without changing the booking rules.
If queries become expensive, the system can maintain a separate read table with those details already assembled. If that table updates asynchronously, a new ticket may not appear immediately; the interface should retain the successful booking confirmation while refreshing the list.
CQRS is useful when updates have substantial business rules while screens or reports need a very different representation. It can apply just to ticket booking rather than the entire system.
For applications that simply create, read, update, and delete straightforward records, one shared model is often easier to develop.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate