CQRS Design Pattern

What is CQRS ?

CQRS is an architectural design pattern whose main focus is on separating the writing and reading responsibilities. CQRS architecture is established based on the CQS principle.

To talk about the main idea of ​​CQS; A method must either change the state of the object or return a result, but it must not do both at once.

If you create your applications according to the CQRS architectural pattern; you can maximize your application’s performance, scalability, and security.

In this approach, methods should be divided into 2 different models:

1.Commands: Changes the state of the object or system. Example insert, delete, update..

public class AddBlacklistCustomerCommand : ICommand
{
    public readonly int Id
    public readonly string BlacklistNote;
    public AddBlacklistCustomerCommand(int id, string blacklistNote)
    {
        Id = id;
        BlacklistNote = blacklistNote;
    }
}

2.Queries: It only returns the result and does not change the state of any object or system. The queries we will create are usually named with the prefix ‘Get’. For example;

public class GetCustomerByIdQuery() : IQuery
{
    public int Id { get; set; }
    public GetCustomerByIdQuery(int id)
    {
        Id = id;
    }
}

When to Use CQRS?

It can be used in structures where there may be complex business rules or where business rules change frequently.

It can be used in systems with high data traffic.

It can be used in separate systems in case of a possible service failure, if this failure does not have a negative effect on the flow of the system.

When Should We Not Use CQRS?

In systems where business rules are simple and do not change much, and in systems where simple CRUD operations are performed.

Advantages of CQRS design pattern

You can use different databases for your read and write operations. (For example, you can use MySQL for write operations and Couchbase for read operations)

Since read and write operations are separated, we do not have to wait for a write operation while performing a read operation.

It can help establish a structure where each team can work on different Domain Logic 🙂

Disadvantages of CQRS design pattern

Increases code complexity. 🙁

If you have an event-based structure, your application must be able to manage errors and repeated operations in the queue.

If you do not take into account possible failover scenarios, you may encounter data loss or even bigger problems.

Finally, In the traditional structure, the same data model is used for reading and writing operations. Although this is simple for applications that perform basic CRUD operations, it can become cumbersome in growing applications. For example; there are many parts in the application where reading operations take place and all of them contain complex queries within themselves and the DTO that will host these query results is complex. Here, there are also operations such as converting this data to DTO (Data Transfer Object), the mapping process is costly and the queries in the model start to become more complex. Since reading and writing operations are performed in the same place, a slow structure will also emerge in terms of performance.

For example, while a relational database is suitable for writing operations, a document-based database can be healthier for reading operations. In this way, both parties will use an efficient process according to their own needs and the traffic coming for the reading operation will not affect the traffic for the writing operation.

Stay with Technology 💙