CQRS — Command Query Responsibility Segregation
Bu link aracılığı ile yazının Türkçe versiyonuna erişebilirsiniz.
What is CQRS?
CQRS is a software development pattern based on conducting reading and writing/updating operations on different models. By taking it a step further, you may think that the data you read and the data you write are stored in different data storage tools.
There are several gains achieved with this method:
- You can scale your system separately according to the intensity of reading and writing operations.
- You can use different data storage tools for your reading and writing operations (For example, you can use PostgreSql for writing operations and Elastic Search for reading operations).
- You can offer your clients meaningful contracts when they send commands to your system to read or write.
- Since you separate the reading and writing processes, you do not have to wait reading operations due to the writing operations.
How CQRS Works?
First of all, we can focus on the term eventual consistency. Consistency means being consistent at all times. Therefore in consistent systems, all models are consistent at any given time. In eventual consistent systems, the models may be inconsistent for a while as a result of writing / updating processes. This situation is resolved after a while and the system will eventually be consistent.
In systems developed using the CQRS software pattern, the write / update requests from the client are transmitted to services on the system as write model. The services check the status of the entity through the write model (the real state of the data) and decide whether the incoming request will be processed or not. If the request is processed, the necessary changes are made to the reading model. When the user queries data, the services answer the requests with the reading model.
When systems that use CQRS save writing model into storage, it is possible to update the reading model with different approaches. One of these methods is to save the writing model and to change the reading model at the same time. Unit of Work design pattern helps us at this point.
Another method is to update the reading model with asynchronous processes after the writing model is saved. This method is the reason we explain the term eventual consistency mentioned above. The second method mentioned is frequently preferred in systems built with CQRS. For this reason, generally systems developed with CQRS design are eventual consistent systems.
Since there is no transactional dependency in eventual consistent systems, reading and writing actions do not wait for each other. For this reason, CQRS systems are used where performance is important.
Software development with CQRS is a costly method. However, if it is used in the right place, it will be easier to maintain the system. For this reason, as in every software development pattern, it should be used where necessary.