Introduction to CQRS
Introduction to CQRS
Learn about CQRS, its benefits for software architecture, and when to use it (and not use it).
Join the DZone community and get the full member experience.Join For Free
Learn why microservices are breaking traditional APM tools that were built for monoliths.
What Is CQRS?
CQRS stands for Command, Query, Responsibility, and Segregation. In CQRS, we divide our read and write operations into two parts one is Command side and another one is Query side. command side handles create, update, and delete. basically command side is used to when data changes and query side is used to get data from the database by executing the query against one or more materialized view.
When Do We Use CQRS?
- When there are multiple operations are performed in parallel on the same data.
- Scenarios when the number of the read operation is higher than the write operation in this situation we need horizontal scaling. In this type of situation, we prefer CQRS.
- Situations when one team of developers can focus on the write side and another team of developers can focus on the read side and user interface.
Benefits of CQRS
- The main and most useful feature of CQRS is that we can do independently scaling ie both horizontal and vertical.
- By using CQRS it is very easy to maintain the security of the database ie. because there are some people who have only read rights and some people who have only write rights and some of the people have both read and write rights. so, In CQRS it 's very easy to maintain security.
- CQRS is also helping us to maintain consistency throughout the independent systems.
- CQRS also help in a situation when the read side is available in case of failure if your write side is down then you can read the last update in the database.
Challenges of CQRS
- When we implement CQRS in our application. It can lead to more complex application design if we also use event sourcing with it.
- In CQRS when we separate read and write side of databases, then read data may be stale.
When CQRS Is Not Recommend
When the domain or the business rules are simple.
Where a simple crud style user interface and the related data access operation are sufficient.
When there is less amount of read and write operations are performed and the database is not too large.
When our database is not distributed.
Opinions expressed by DZone contributors are their own.