# Command Query Responsibility Segregation (CQRS)

<figure><img src="https://415484505-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LxtoAXZwwOc4XGto8vb%2Fuploads%2Fksk9fdVffWRs7uDkSzS5%2FScreenshot%202022-09-23%20at%2009.18.37.png?alt=media&#x26;token=6de2658d-fd06-4c33-b613-30eb5ce4036a" alt=""><figcaption></figcaption></figure>

[Taken from Uncle Bob](https://martinfowler.com/bliki/CQRS.html)

* Model for read and write are different
* CQRS fits well with [event-based programming models](https://martinfowler.com/eaaDev/EventNarrative.html). It's common to see CQRS system split into separate services communicating with [Event Collaboration](https://martinfowler.com/eaaDev/EventCollaboration.html). This allows these services to easily take advantage of [Event Sourcing](https://martinfowler.com/eaaDev/EventSourcing.html).
* Having separate models raises questions about how hard to keep those models consistent, which raises the likelihood of using [eventual consistency](http://www.allthingsdistributed.com/2008/12/eventually_consistent.html).

CQRS is useful in some places, but not in others. Many systems do fit a CRUD mental model, and so should be done in that style. **CQRS is a significant mental leap for all concerned**, so **shouldn't be tackled unless the benefit is worth the jump**. While I have come across successful uses of CQRS, so far the majority of cases I've run into have not been so good, with CQRS seen as a significant force for getting a software system into serious difficulties.

Main **benefit** is in handling **high performance applications**. CQRS allows you to **separate the load from reads and writes allowing you to scale each independently**.

