When to Adopt CQRS? Balancing Read/Write Models for Scalable Backend Systems

Overview

From the beginning, software systems have been used for various purposes, and their requirements have grown over time. Requirement changes may involve business logic, scalability, or other aspects of the system.

To satisfy these conflicting or overlapping requirements, engineers must make many trade‑offs when designing a system. The problem is that many trade‑offs are not needed at first, and when they become necessary the system has already evolved to a point where making the trade‑off is difficult.

In my view, the most harmful design lock‑ins usually occur at the data layer. When designing a typical application data model, both domain knowledge and performance considerations are taken into account. Domain knowledge defines what entities are and how they relate logically; performance considerations decide how they are implemented physically (e.g., relational vs NoSQL databases, primary keys, indexes). These choices enable the application to serve its target scenarios effectively.

In large applications with massive data and complex entity models, some implementation details become “core” over time. Sometimes these are introduced deliberately, but more often they arise implicitly or unintentionally. Consequently, new requirements may conflict with existing implementations, making it impossible to accommodate them cleanly.

This article focuses on a situation where the way data is read from an application differs significantly from the way data is written to the system. The differences may involve query patterns, output formats, or scale.

In the example I describe, an order‑management system used entity IDs (order ID, product ID, etc.). Over time, complex read requirements emerged that the existing data model could not support. The problem manifested in two ways: the current implementation struggled to satisfy new query patterns, and the data consumers wanted a completely different data model. For instance, sellers on an e‑commerce platform wanted large‑client data slices presented in a specific way, while customer‑facing applications expected the data to look like it does in a shopping cart.

Such situations are common for systems with core entities whose encapsulated data is widely used and therefore needs to be offered in multiple formats.

CQRS

CQRS stands for Command Query Responsibility Segregation. In a CQRS‑based system, the command (write) model and the query (read) model use different data representations. The command model is optimized for write/update operations, while the query model is optimized for various read patterns. Changes in the command model are propagated to the query model through domain events or other mechanisms to keep the data synchronized.

If you think of them as two separate microservices, note a subtle difference: physically they can be implemented as independent services, or a single command model can serve multiple query models. However, in microservice architecture the two services usually represent distinct domains, whereas in CQRS both models belong to the same logical domain. The query model must be aware of the command model; this coupling is intentional and differs from the decoupling typical of microservices.

CQRS does not prescribe how the two models stay synchronized. Synchronization can be achieved by updating both models simultaneously, or by using a message broker (e.g., Kafka) to transfer commands from the command model to the query model asynchronously. The latter is common because it improves scalability, though it requires trade‑offs regarding eventual consistency for write and read operations.

This Isn’t Just Caching

A read‑only data model may look like a cache. In fact, a query model can be implemented using caching technologies such as Redis. However, CQRS is not merely about separating reads and writes; its core purpose is to provide multiple representations of data, each satisfying specific user needs. Different query models may use different physical implementations—some databases, some caches, etc.

When to Use CQRS

CQRS is valuable in several scenarios.

First, as mentioned earlier, if a single data model cannot efficiently satisfy both read and write patterns, decoupling them with CQRS makes sense. The separated models can each meet their specific requirements while staying consistent with the core model that handles all updates.

The second scenario is separating read load from write load. While caching also separates reads, CQRS allows each model to have its own database and cache, using the most suitable technology for each case. The command model’s scalability is not constrained by the query model, and vice versa, even though the models are deeply coupled.

When Not to Use CQRS

Introducing CQRS adds significant cognitive overhead and complexity. Developers must manage at least two data models and multiple technology choices, which is a non‑trivial burden.

Another challenge is keeping the command and query models synchronized. An asynchronous approach introduces eventual consistency, which can be problematic when users expect immediate reflection of their actions.

If you require strong consistency at all times, you face CAP and two‑phase‑commit issues. Using a single ACID‑compliant database allows transactional consistency, but many scalability benefits of CQRS are lost. Supporting multiple query models can also slow write operations because every update must propagate to all query models.

Because of these issues, careful consideration is required before adopting CQRS. When used appropriately, it can greatly improve scalability, but supporting multiple data models is not easy and should only be considered when no other solution meets the requirements.