The Command Query Responsibility Segregation (CQRS) pattern isolates the data querying aspects of an application from the insert, update and delete operations. There are limited use cases regarding when you should use this pattern and it doesn’t apply to request response style scenarios where the updated results may need to be displayed to the user immediately after an insert / update / delete. You must carefully evaluate your requirements to determine if CQRS is suitable to address your architectural requirements. Typically, requirements that are more sophisticated than just information systems driven CRUD operations, such as information in different transient states of representation, are good candidates for CQRS.
Event Sourcing is a useful scenario where the CQRS pattern can be leveraged. In an event sourcing scenario, the application stores state transitions as events in an event store. The read and write models in the scenario may be in different states, but the application eventually gets a consistent current state by playing the events in sequence. A good example is a highly scalable hotel reservation system in which certain attributes of the reservation can be modified until midnight of the day before arrival. The query and command operations in this scenario can be dealt with separately using the CQRS pattern where the states maybe not in sync but will eventually become consistent to determine the current state of the reservation.