Command Query Responsibility Segregation (CQRS) is an development architectural design or pattern that separates reading and writing into two different models. It does responsibility segregation for the Command model & Query model.
Command Model - Modifies data (e.g. Insert, Update & Delete actions)
Query Model - Never modifies data (e.g. Select action)
From the below diagram, you can see that the read and write models have separate responsibilities. The Command model (Write model) is responsible for validation, commands, complex domain logic, and data persistence. However, the read model (Query model) is responsible only for reading data, which makes it quite simple.
Advantages of the CQRS Pattern
Single Responsibility Principle
As you can see in the above diagram, there are separate models, read & write. It means a method should be either Command or Query. With this separation, you get the Single Responsibility Principle by design.
Independent Scaling
Let's assume you have a website which has more reads than write (something like devstoc.com). In such a case, you can scale your read models to get better performance.
Also, you can use two separate databases for the read & write models. With this approach, the write model will send a command to the write database (then it will asynchronously update the read database), and the read model will fetch data from the read database. Furthermore, you can denormalise a read database that will result in simple queries, less complex joins, quick response time, etc. You can even use NoSQL for the read database. Then, you can scale your models independently. Thats why, one of the major benefits of the CQRS pattern is Independent scaling.
Separation of Concern
With the two separate models to read & write, you can keep validations, complex logic into the write model only and keep your read models simple to fetch the data. Similarly, your Command model will be responsible for writing to the model(s)
Disadvantages of the CQRS Pattern
Although the CQRS pattern is easy to understand, in real-time scenarios it can be painful if not implemented correctly. Below are the few drawbacks of this pattern:
- It adds unnecessary complexity if applications have simple Create Read Update Delete operations, which can be achieved by traditional architectural styles.
- As we require separate models for read & write, code duplication is undeniable.
- In the case of two separate databases for read & write, the write database needs to update the read database that could result in Eventually Consistent Views.
When to use the CQRS Pattern
Below are some scenarios where the CQRS pattern fits perfectly:
Scenario #1
Large projects where high performance is required and independent scalability is required.
Scenario #2
In the applications where business logic is complex. In such a case, you can separate your reads from write to make it more simple.
Scenario #3
If you want parallel development where one team can work on the read models & other team works on write models.
Recommended articles on CQRS Pattern
Below are the most viewed articles and liked by many developers:
- Microservices With CQRS and Event Sourcing
- CQRS: What? Why? How?
- Pattern: Command Query Responsibility Segregation (CQRS)
- CQRS pattern - Azure Architecture Center
Please leave us your comments Have you used CQRS Pattern or not?