CQRS | Pattern & It's Concept

In this article we will dive into the concepts of CQRS, understanding its meaning, why it is required, and its advantages.

CQRS Pattern

CQRS is a simple pattern and it stands for Command Query Responsibility Segregation, which enables fantastic possibilities. As the name suggests, we split the application into two parts: Command-Side and Query-Side. Now, one will ask, what do "Command" and "Query" mean?

Command

• Change the state of the object or entity, also called modifiers.
• A Command is the only way to change the state of our system.
• Commands are responsible for introducing all changes to the system.
• Commands should not return any value.

Query

• Return the state of the entity and do not change anything. Another term for them is "accessors."
• A Query is a read-only operation.
• With a Query, we read the state of a part of our system.
• We can do filters, projections, and all sorts of data transformations to deliver data to the UI in the most useful format.
• A Query does not modify the state of our system. It can be run many times without side-effects.

This simple separation enables us to do many interesting things from an architectural point of view. This means that the data models used for querying and updates can be different. They can stay in the same data store or be completely different.

Why Is It Required?

In traditional data management systems, both commands and queries are executed against the same set of entities, having a single representation, or view. CRUD operations are applied to a single data store and the same entity or object is accessed to handle both read and write operations.

There are issues with having a single view for both read and write sides:

• Introduces the risk of data contention.
• Managing permissions and security become complex as the same objects are exposed to both read and write operations.

How CQRS Solves This Problem

The CQRS pattern holds the idea that the method should either change the state of the entity, or return the result, but not both. Segregating models for the read and write sides reduces the complexity that comes with having a single view for both of them.

Benefits of CQRS:

• Separate command and query models, resulting in simplified design and implementation of the system and overall reduction of complexity.
• One can easily optimize the read side of the system separately from the write side, allowing scaling of each differently as per the load on the side. For example, read data stores often encounter greater load, and hence can be scaled without affecting the write data stores.
• You can provide multiple views of your data for querying purposes depending on the use cases.
• The number of reads being far higher than the number of modifications inside an application, applying the CQRS pattern allows to focus independently on both concerns. One main advantage of this separation is scalability: we can scale our reading part differently from our writing part (allocate more resources, different types of database).
• It’s easy to update or add on the reading side, without changing anything on the writing side. Data consistency is therefore not altered and is Flexible.

How CQRS Works

CQRS is mainly used in conjunction with Event Sourcing. The write side model of the CQRS-based system handles the events persistence, acting as a source of information for the read side. The read model of the system provides materialized views of the data, typically as highly denormalized views.

The diagram below provides the detail flow of a CQRS-based system:

Recap

CQRS is a simple pattern, which enables fantastic possibilities. It consists in separating the reading part from the writing part, with queries and commands.

Many advantages result from its usage, especially in term of flexibility and scaling.

Event sourcing completes the CQRS pattern by saving the history that determines the current state of our application.

Let me know your thoughts and experiences about this in comments......