# Bliki: CQRS  URL:: https://martinfowler.com/bliki/CQRS.html Author:: martinfowler.com ## Highlights > CQRS stands for Command Query Responsibility Segregation. It's a pattern that I first heard described by Greg Young. At its heart is the notion that you can use a different model to update information than the model you use to read information. For some situations, this separation can be valuable, but beware that for most systems CQRS adds risky complexity. ([View Highlight](https://instapaper.com/read/1411956451/16378873)) > The mainstream approach people use for interacting with an information system is to treat it as a CRUD datastore. By this I mean that we have mental model of some record structure where we can create new records, read records, update existing records, and delete records when we're done with them. In the simplest case, our interactions are all about storing and retrieving these records. ([View Highlight](https://instapaper.com/read/1411956451/16378876)) > The change that CQRS introduces is to split that conceptual model into separate models for update and display, which it refers to as Command and Query respectively following the vocabulary of CommandQuerySeparation. The rationale is that for many problems, particularly in more complicated domains, having the same conceptual model for commands and queries leads to a more complex model that does neither well. ([View Highlight](https://instapaper.com/read/1411956451/16378881)) > A web example would see a user looking at a web page that's rendered using the query model. If they initiate a change that change is routed to the separate command model for processing, the resulting change is communicated to the query model to render the updated state. ([View Highlight](https://instapaper.com/read/1411956451/16378884)) > The in-memory models may share the same database, in which case the database acts as the communication between the two models. However they may also use separate databases, effectively making the query-side's database into a real-time ReportingDatabase. In this case there needs to be some communication mechanism between the two models or their databases. ([View Highlight](https://instapaper.com/read/1411956451/16378886)) > we can easily move to a task-based UI. ([View Highlight](https://instapaper.com/read/1411956451/16378895)) > CQRS fits well with event-based programming models. ([View Highlight](https://instapaper.com/read/1411956451/16378896)) > Having separate models raises questions about how hard to keep those models consistent, which raises the likelihood of using eventual consistency. ([View Highlight](https://instapaper.com/read/1411956451/16378897)) > If the write model generates events for all updates, you can structure read models as EventPosters, allowing them to be MemoryImages and thus avoiding a lot of database interactions. ([View Highlight](https://instapaper.com/read/1411956451/16378900)) > CQRS is suited to complex domains, the kind that also benefit from Domain-Driven Design. ([View Highlight](https://instapaper.com/read/1411956451/16378901)) > In particular CQRS should only be used on specific portions of a system (a BoundedContext in DDD lingo) and not the system as a whole ([View Highlight](https://instapaper.com/read/1411956451/16378903)) > 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. ([View Highlight](https://instapaper.com/read/1411956451/16378904)) > Firstly is that a few complex domains may be easier to tackle by using CQRS. ([View Highlight](https://instapaper.com/read/1411956451/16378905)) > The other 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. ([View Highlight](https://instapaper.com/read/1411956451/16378908)) --- Title: Bliki: CQRS Author: martinfowler.com Tags: readwise, articles date: 2024-01-30 --- # Bliki: CQRS  URL:: https://martinfowler.com/bliki/CQRS.html Author:: martinfowler.com ## AI-Generated Summary None ## Highlights > CQRS stands for Command Query Responsibility Segregation. It's a pattern that I first heard described by Greg Young. At its heart is the notion that you can use a different model to update information than the model you use to read information. For some situations, this separation can be valuable, but beware that for most systems CQRS adds risky complexity. ([View Highlight](https://instapaper.com/read/1411956451/16378873)) > The mainstream approach people use for interacting with an information system is to treat it as a CRUD datastore. By this I mean that we have mental model of some record structure where we can create new records, read records, update existing records, and delete records when we're done with them. In the simplest case, our interactions are all about storing and retrieving these records. ([View Highlight](https://instapaper.com/read/1411956451/16378876)) > The change that CQRS introduces is to split that conceptual model into separate models for update and display, which it refers to as Command and Query respectively following the vocabulary of CommandQuerySeparation. The rationale is that for many problems, particularly in more complicated domains, having the same conceptual model for commands and queries leads to a more complex model that does neither well. ([View Highlight](https://instapaper.com/read/1411956451/16378881)) > A web example would see a user looking at a web page that's rendered using the query model. If they initiate a change that change is routed to the separate command model for processing, the resulting change is communicated to the query model to render the updated state. ([View Highlight](https://instapaper.com/read/1411956451/16378884)) > The in-memory models may share the same database, in which case the database acts as the communication between the two models. However they may also use separate databases, effectively making the query-side's database into a real-time ReportingDatabase. In this case there needs to be some communication mechanism between the two models or their databases. ([View Highlight](https://instapaper.com/read/1411956451/16378886)) > we can easily move to a task-based UI. ([View Highlight](https://instapaper.com/read/1411956451/16378895)) > CQRS fits well with event-based programming models. ([View Highlight](https://instapaper.com/read/1411956451/16378896)) > Having separate models raises questions about how hard to keep those models consistent, which raises the likelihood of using eventual consistency. ([View Highlight](https://instapaper.com/read/1411956451/16378897)) > If the write model generates events for all updates, you can structure read models as EventPosters, allowing them to be MemoryImages and thus avoiding a lot of database interactions. ([View Highlight](https://instapaper.com/read/1411956451/16378900)) > CQRS is suited to complex domains, the kind that also benefit from Domain-Driven Design. ([View Highlight](https://instapaper.com/read/1411956451/16378901)) > In particular CQRS should only be used on specific portions of a system (a BoundedContext in DDD lingo) and not the system as a whole ([View Highlight](https://instapaper.com/read/1411956451/16378903)) > 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. ([View Highlight](https://instapaper.com/read/1411956451/16378904)) > Firstly is that a few complex domains may be easier to tackle by using CQRS. ([View Highlight](https://instapaper.com/read/1411956451/16378905)) > The other 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. ([View Highlight](https://instapaper.com/read/1411956451/16378908))