Reading time: 3 minutes
CQRS: fad or performance enhancer?
26 / 07 / 2017
New trends in e-commerce mean that system architects continue to face fresh challenges. The market pressurizes online stores to present a customized range adjusted to suit even the most demanding of customers rather than act as a static product catalogue.
This results in an increasing amount of data and, consequently, problems with information processing. Should architects use CQRS, a pattern that has been gaining great popularity recently, to eliminate these problems?
User details and user behaviour data provide valuable information for online store owners nowadays. With insight into what products customers browse and add to their carts, and what time of day most visit the store, the range can be customized to the individual consumer’s expectations. With such knowledge, purchasing decisions can be easily supported with various processes, such as by providing an option to view recently viewed and most popular products.
Moreover, there are many mechanisms out there to maintain the attention of customers at the moment they are planning to quit the checkout path. These involve defining those consumer behaviours that indicate indecision or unwillingness to finalize the order. At this point, presenting a discount offer motivates the consumer to finalise their purchase. Another proven method is to remind them of their abandoned basket.
By collecting and analysing information about the customers’ shopping preferences, we can put them to use at the right time, which could be by suggesting to the user that they choose a new jacket for the winter season (if you know that this user buys a jacket every December). While all these mechanism contribute to increasing e-commerce sales, they demand an architecture that ensures fast performance, stability and scalability.
So is CQRS a real solution or just a fad?
System architects need to consider the system’s lifetime, development and growing popularity, and therefore aim to ensure high performance, stability and the possibility of introducing modifications that address increasing requirements. Using the CQRS pattern has become a frequent topic discussed by designers. The question is whether CQRS is the key to success or just a fad? There are many resources and examples available online that describe CQRS, so we are going to focus on how it can be applied in order to improve the performance of a system.
Architects need to classify design problems into two groups: those that require strict control, and those that need to be completed within a specific timeframe to ensure the operation is successful. Let us illustrate this with an example: “The critical operations for placing an order include checking the inventory levels and calculating the prices of the products being sold, whereas operations such as sending an email notification, saving statistics or submitting the order to external systems are not critical.” The operations which are not of critical importance can be executed asynchronously to take some load off the main process. In this case, asynchronicity means delegating some operations to be executed by backend processes that run in the background.
This seems easy in theory, but what is it like in practice? Let us consider a scenario where we experience a problem with collecting information about the products viewed by the user. Is this operation critical for the system? No: the information is valuable, but so is the user comfort and, consequently, the response time. With CQRS, you can easily send operations to be executed asynchronously. The information about the user viewing a product creates a command, which can be easily queued and then processed by backend processes. See Figure 1 for how this works.
Figure 1. Scheme of asynchronous operation execution
Our example clearly shows that CQRS is not just a passing trend. The principle is not only about separating the logic of saving and reading data: it can also be applied to enhance the system’s flexibility, with asynchronous processing, for example.