A guide to CQRS Pattern from the first Principle

cqrs — frederich blessy

Presently, we can see millions of users can read and write data into application, and it’s almost simultaneously. Let’s say we’re dealing with a complex applications such as microservices that has a high volume & demand for data consumption. So new approaches are needed.

A CQRS stands for Command and Query Responsibility Segregation, is one of approach coined by Greg Young. CRQS is an architectural pattern that separates the process of writing and reading data in different process and services.

CQRS implementation can optimize its performance, scalability, and security.

Separating writes & reads

In the microservices case, data is stored in different databases. For example, assuming we have user-db for users data & post-db for posts data and post has author_id that is referenced to id in user table. However, the expected result should be like this;

// example expected result as json
{
  "id": 431331,
  "name": "Geralt Rivia",
  "posts": [
    {
      "id": 1,
      "author_id": 431331,
      "title": "CQRS Basic",
      "body": "The body of CQRS"
    },
    {
      "id": 2,
      "author_id": 431331,
      "title": "Microservice Basic",
      "body": "The body of Microservice"
    },
  ]

}

This case, in process of retrieve or search data will required effort which may very heavy in the process. In the common technique, most data is taken from each service, then combined in the code level, then displayed. It will affect the response time & performance of searching will be decreased and be very slow.

In the CQRS solution is by creating a separate database such as view database that is read only and different service to handle the database. In that case, we will able to improve the search performance. The database we created is kind of like an aggregator of several services involved and it usually apply denormalization rules to the table. Thus, the search process becomes faster, scalable, and will ultimately improve the overall performance.

Eventual Consistent

But we should know that this procedure means that the read and write databases must be synchronized. If writes and reads are separated in different database, clearly that the distributed transactions aren’t very suitable means and the read data may be stale.

To make it simpler, I put the example diagram of CQRS in a nutshell below.

cqrs in simple microservice — frederich blessy

According to the diagram, post service is the aggregator for user service. Post service does the Create, Update & Delete through Command and will process & store the data. If the data successfully stored, the Event Handler will sync the data to Query Database. Otherwise, to post service gets its data through Query from Query Database that has already synchronized.

Event Sourcing

Commonly, the problem with CQRS is how incoming data could be processed quickly and correctly because a lot of data sometimes arrives simultaneously which eventually will block or take a long time in data processing and storing. To handle this, most of way is to use data processing asynchronously and using event driven (event base).

Event sourcing is technology that used most in CQRS pattern. We also have to determine the right type of database to use as an aggregator. The common choices are like redis for caching and elasticsearch is for search engine for those types are have designed for faster & scalable data retrieval purpose.

When to use CQRS:

• When the application has a high demand for data consumption.
• When having large difference between the number of reads and writes or number of reads is greater than number of writes.
• When having a complex business logic or domain model.
• When performance is critical. You can implement CQRS to optimize read and write sides by separating it.

When not to use CQRS:

• When having a simple business logic or domain model, then of CQRS would be have much effort or too overwhelming.
• CQRS is not the whole solution. You don’t need it for every system. Focus to the context which really needs CQRS.

Conclusion

So with CQRS, the read database is only for reading the data and creating materialized views and the write database is only for making changes.

When implementing CQRS, the read data may be stale. But it’s better to get a response, even if it may a bit outdated than nothing at all.

The CQRS is not the whole solution. It’s not always necessary, focus on the context which really needs CQRS.