Concepts of CQRS
In the previous blog, we have learnt what Event Sourcing is. Moving forward, we will dive into the concepts of CQRS, understanding its meaning, why is it required and its advantages.
CQRS Pattern
CQRS stands for Command Query Responsibility Segregation. As the name suggests, we split the application in two parts: Command-Side and Query-Side. Now one will ask what this command and query means? Okay, so -
- Commands are the ones that change the state of the object or entity, also called modifiers or mutators.
- Queries are those that returns the state of the entity, and do not change anything. The another term for that will be accessors.
Why is it required?
In traditional data management systems, both commands and queries are executed against the same set of entities, having a single reprsentation or view. The CRUD operations are applied to a single datastore, the same entity or object is accessed to handle both read and write operations.
Issues with having single view for both read and write side -
- Introduces the risks of data contention.
- Managing permissions and security become complex as 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 returns the result, but not both. Segregating models for read and write side reduces the complexity that comes with having single view for both of them.
Benefits of CQRS -
- Separate command and query models, results in simplified design and implementation of the system and overall reduction of complexity.
- One can easily optimise the read side of the system separately from the write side, allows scaling each differently as per the load on the side. For example — Read datastores often encounters greater load, and hence can be scaled without affecting the write datastores.
- You can provide multiple views of your data for querying purpose depending on the use cases.
How CQRS works?
CQRS is mainly used in conjuction 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.
Below diagram provides the details of the CQRS based system.
How to implement Event Sourcing and CQRS?
If you are using microservices architecture to build your applications and want to utilise the benefits of Event Sourcing and CQRS, various frameworks and platforms are available for developing asynchronous microservices.
1. Eventuate is one such example. It is an application platform, consisting of two products, one of which is Eventuate ES — a microservices framework that implements an event sourcing-based programming and persistence model.
2. Lagom is an open source micro-service framework built on top of Akka and Play framework. Lagom Persistence makes use of Event sourcing and CQRS to help achieve the decoupled architecture.
You can find the real life example of how Lagom handles Event Sourcing and CQRS in the following blogs :
3. Axon is a lightweight framework that helps developers build scalable and extensible applications based on the CQRS principles. It does so by providing implementations of the most important building blocks, such as aggregates, repositories and event buses.
References
- http://microservices.io/patterns/data/cqrs.html
- https://www.codeproject.com/Articles/555855/Introduction-to-CQRS
- https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs
Happy Blogging.! :)
