CQRS in Microservices

Bertrand Meyer defines the term Command Query Segregation as meaning that an object’s method should be either a query or a command. A query is therefore a method that returns data. While a command is intended to modify data. Whether it’s adding new data or updating existing data.

The design pattern Command Query Responsibility Segregation (CQRS) picks up on this definition but takes it to an architectural level. The diagram shows an example of how such an architecture can be designed. The key is the separation of logic into a query side and a write side. A reference implementation according to the diagram accordingly bundles all query logic on the query side. While the write side in turn contains the logic to modify, update, or delete data.

Theoretically, the CQRS pattern can be taken so literally that even the database is split. This creates the possibility of optimizing the write side’s database for writing data, while the query side’s database can be optimized for queries. To keep the data states consistent in both databases, changes in the write side database must consequently be communicated to the query side database. However, separating the database means additional complexity, which is why it should be weighed on a case-by-case basis whether this separation makes sense.

The advantage of the separation according to the CQRS pattern is particularly the independent implementation of query and write logic. This comes with easier scaling, because in some cases it can be particularly relevant to optimize the system’s write performance. Due to the separation, the optimization can be implemented independently of the query side. Furthermore, the independent implementation reduces complexity because write operations and queries can be viewed as independent problems. The separation also leads to a more easily extensible system since there are fewer side effects and dependencies.