When an application has too many read operations, the system starts to slow down. Especially if the number of changes to the data remains small. In such situations, the classic CRUD architecture fails: the same storage processes both requests and commands, which leads to competition for resources and reduced performance. Do you know what is CQRS Pattern, let’s know.
CQRS, an architectural pattern that separates the processing of commands and requests, helps solve this problem. This approach is especially useful in microservice architectures, where the load may be uneven.
In this article, we will look at how CQRS works, what tasks it solves, and how it can be useful in real projects.
What is CQRS
CQRS (command and query responsibility segregation) is an architectural pattern that proposes to separate the operations of changing data ( commands ) and reading data ( queries ). This approach helps to simplify the application logic, especially if the read and write loads differ significantly.
Imagine a blogging platform. Every day, dozens of authors publish new articles, and millions of users read them. The number of read operations here is dozens of times greater than the number of change operations. In such cases, CQRS allows you to optimize the application: a separate model is designed for reading, and a separate one for writing.
The essence of the pattern is to separate two types of operations:
- Commands – change the state of the system. For example, create an article, update a profile, or delete a comment. Commands usually do not return data, but only initiate a change.
- Queries — read data without changing it. Their task is to return the required information as quickly as possible. Often, specialized models, databases or cache are used for this.
Requests and commands work independently of each other, which makes the architecture flexible and more predictable under load. You can always understand why the system is slowing down and optimize that particular part of the application.
What does CQRS consist of?
Imagine that you have a backend of an online store developed on the basis of the CQRS pattern. The system has commands that make changes to the database (create and edit orders) and queries (display information about orders). In addition, our store has a user interface through which customers interact with it, and separate databases for commands and queries. To communicate between databases, a synchronization module is provided that updates the data.
Commands and queries cannot exist on their own. They are combined into modules — files that contain all the necessary functions, classes, and variables. Let’s consider which modules are most often found in projects based on the CQRS pattern.
Command module
If the user adds products to the cart and places an order, these operations will be processed by the command module:
- The handler will accept the user name, product name, quantity and enter the order information into the database.
- The validator will check the commands for correct input data and make sure that the user is authorized. For example, if the buyer orders a product that is not in stock, the system will return an error.
Query module
Online store users not only place orders, but also request information. For example, to find out the delivery status or download an electronic receipt. These operations do not make changes to the database, so they are performed by a separate request module:
- The handler provides data in response to a request (for example, to download an order receipt). It may access a separate database that stores information optimized for reading.
- The optimizer speeds up query execution. For example, special databases with fast access, indexing and caching can be used for acceleration.
Additional components
For more convenient work, the following elements are often used together with the CQRS pattern:
- Synchronization mechanisms are systems that coordinate data between separate systems for reading and writing information. In our example, there are two databases: the system makes changes to one, and receives data from the other. The synchronization module updates information between the databases so that users receive up-to-date data without delays.
- Aggregates are groups of objects united by common business logic and data integrity. For example, an order that includes information about the buyer, product, and payment can be an aggregate. In this case, all changes to the order will be processed as a single whole.
- Domain services are services responsible for performing domain-specific operations that do not fit into a single aggregate. For example, a discount calculation service can combine data from multiple orders or even external sources to determine the final cost of a purchase when the logic is distributed across different parts of the system.
CQRS by example: writing the backend of an online store
To better understand how the CQRS pattern works, let’s develop a backend for an online store in Python. In the code, we’ll separate the request and order processing modules. This will allow us to edit the modules independently.
If you write code in another programming language, you will find it relatively easy to understand our project. If you are just starting to learn development, we recommend that you pay attention to our Python guide .
Project structure
In the example with an online store, two strategies can be applied: write the entire backend in one file or split the project into modules. Let’s assume that users will check order statuses more often than make purchases. At the same time, anomalies will occur before the holidays – both the number of orders and the number of database requests will increase.
To ensure that the system can handle such loads and we can scale it if necessary, we will apply the CQRS pattern – that is, we will divide responsibility for commands (data changes) and requests (data retrieval).
This is the key idea of CQRS: commands and queries should be implemented independently of each other. At the project structure level, it looks like this:
- models.py — a simulation of a data warehouse (instead of a database), describes the structure of orders.
- commands.py – functions for creating and updating orders.
- queries.py – functions for obtaining information about an order.
- app.py is the main file that combines both parts.
Data storage
To avoid wasting time on setting up a database, we will store data directly in Python — in memory. This approach is suitable only for demonstration. If you want to use CQRS in a real project, be sure to connect a full-fledged DBMS.
Let’s start with the models.py file . In it, we’ll describe the Order class with the following fields:
- order_id — unique order identifier.
- customer — the name of the buyer.
- product — the name or object of the product.
- quantity — quantity of goods.
Command processing
Our online store already knows how to save the history of user orders in memory. Now in the commands.py file we will create functions for managing orders.
For simplicity, we will implement two commands:
- create_order — creates a new order.
- update_order — edits an existing one.
The create_order function takes data in the format we described in the models.py file using the Order class , and checks the order_id field . If an order with the specified number already exists in the database, the function will return an error. Otherwise, create_order will create an order and save it in the order_store variable .
Processing requests
An important part of any online store is the ability to check the status of an order. Without it, users will not be able to track the delivery, and the customer service will not be able to find out what the buyer ordered in order to issue a return.
Checking the status does not change the data, but only requests it. In the CQRS pattern, such operations are taken out to a separate module. We will do the same – create a queries.py file and implement the get_order function in it .
Note : This function does not generate an event, since status queries typically do not require notifications, logging, or passing to an analytics system. get_order simply returns a dictionary with order information.
Why did we separate commands and queries?
In our architecture, commands ( create_order , update_order ) and queries ( get_order ) are in different modules. This makes the system flexible: they can be developed independently.
For example, if we notice from analytical reports that users have started to place orders more often and check their status less often, we can redistribute resources without having to rewrite the entire platform.
Let’s start with the models.py file . In it, we’ll describe the Order class with the following fields:
- order_id — unique order identifier.
- customer — the name of the buyer.
- product — the name or object of the product.
- quantity — quantity of goods.
The Order class is a constructor that we can use to quickly create new orders in the system.
Why did we separate commands and queries?
In our architecture, commands ( create_order , update_order ) and queries ( get_order ) are in different modules. This makes the system flexible: they can be developed independently.
For example, if we notice from analytical reports that users have started to place orders more often and check their status less often, we can redistribute resources without having to rewrite the entire platform.
