CQRS Pattern: Understanding Command Query Responsibility Segregation

Introduction
What is CQRS?
Why Separate Reads and Writes?
CQRS Architecture and Workflow
Data Synchronization Strategies
CQRS and Event Sourcing
When Should You Use CQRS?
FAQ

Introduction

When we first learn to build web applications, the most common pattern we use is CRUD (Create, Read, Update, Delete). In a traditional CRUD architecture, we use the exact same data model to perform both write operations (inserting, editing, deleting) and read operations (fetching and displaying data).

This approach works exceptionally well for small to medium-scale applications because it is simple, intuitive, and fast to implement. However, as traffic grows and business logic becomes more complex, this single-model approach begins to show its limitations. Complex read queries (such as analytics reports or multi-criteria search engines) require denormalized, flattened data structures to remain fast, whereas write operations require a normalized data structure to maintain transactional integrity.

To resolve this conflict of requirements, the CQRS (Command Query Responsibility Segregation) architectural pattern was introduced. CQRS splits the responsibility of writing and reading data into completely separate pathways.

What is CQRS?

CQRS was first introduced by Greg Young based on the Command Query Separation (CQS) principle formulated by Bertrand Meyer. The core idea is straightforward: Separate operations that modify data from operations that only read data.

In practice, CQRS divides application responsibilities into two distinct models:

Commands (Write Model)
- Responsible for modifying the state of the system (Create, Update, Delete).
- Focused on validating business rules and preserving data integrity.
- Ideally, Commands do not return any data to the client, except for a status of success/failure (or minimal metadata such as the ID of the newly created entity).
Queries (Read Model)
- Responsible for fetching data from the system to display to the user.
- Entirely side-effect free—running a query must never alter the system’s state.
- Focused on response speed and formatting data into ready-to-use DTOs (Data Transfer Objects) optimized for the UI.

Why Separate Reads and Writes?

Separating reads and writes may feel like introducing extra overhead, but it offers huge benefits for large-scale production systems:

Independent Optimization: You can design a highly normalized write database (3NF) to optimize for write performance and transaction safety. Conversely, your read database can be completely denormalized (flat tables) so that read queries require no complex, CPU-heavy JOIN operations.
Flexible Scalability: In most web applications, the read-to-write ratio is heavily skewed—often reaching 10:1 or even 100:1. With CQRS, you can scale out your query servers and read replicas independently without having to scale the main write database.
Simplified Business Logic: Since the Query side has no business validations, and the Command side does not have to worry about complex UI formatting, the code becomes highly cohesive, clean, and easier to maintain.
Enhanced Security: You can apply fine-grained security policies. For example, you can grant write permissions only to specific internal microservices while leaving the read models accessible via read-only channels to public clients.

CQRS Architecture and Workflow

Here is how data flows in an application implementing the CQRS pattern:

graph TD
    Client[Client / UI] -->|1. Send Command / Write| Controller[Controller / API]
    Client -->|4. Send Query / Read| Controller
    
    subgraph Command Side - Write Model
        Controller -->|Command| CmdHandler[Command Handler]
        CmdHandler -->|Update State| WriteDB[(Write Database)]
    end
    
    subgraph Query Side - Read Model
        Controller -->|Query| QryHandler[Query Handler]
        QryHandler -->|Fetch Data| ReadDB[(Read Database)]
        ReadDB -->|Return DTO| QryHandler
    end
    
    WriteDB -->|2. Event / Sync| SyncProcess[Synchronization / Message Broker]
    SyncProcess -->|3. Project Data| ReadDB
    
    QryHandler -.->|5. Return Data| Client

Explaining the Workflow:

Command Flow: A user performs an action (e.g., registering a new account). The Controller treats this as a Command and passes it to a Command Handler. Once the business rules are validated, the change is written to the Write Database.
Synchronization: Following the database update, a synchronization event is dispatched (e.g., via a Message Broker like Kafka or RabbitMQ).
Projection: A background consumer processes the event and updates the Read Database with the latest information.
Query Flow: When another user requests to view the list of registered users, the request is treated as a Query. The Controller routes it to the Query Handler, which directly fetches the ready-to-read data from the Read Database without executing any complex business rules.

Data Synchronization Strategies

The most prominent challenge in CQRS is keeping the read model synchronized with the write model. There are two primary strategies to handle this:

1. Synchronous Projection (Strong Consistency)

The Command Handler updates both the write database and the read database within the same database transaction block (atomic transaction).

Pros: Data is instantly consistent. As soon as the write operation completes, the user sees the updated data.
Cons: Write latency increases because the system must write to two places. If the read database is down, the entire write transaction fails.

2. Asynchronous Projection (Eventual Consistency)

The read database is updated in the background using an event-driven model. Once the write database successfully commits, the system publishes a domain event. A message listener processes this event asynchronously to update the read database.

Pros: Extremely fast write operations. The write database is decoulped from the read database, meaning writes can still succeed even if the read database goes offline.
Cons: Introducing Eventual Consistency. There will be a brief delay (ranging from milliseconds to seconds) before the newly written data appears in the read database.

CQRS and Event Sourcing

While CQRS and Event Sourcing are frequently mentioned in the same breath, they are distinct patterns. You can use CQRS without Event Sourcing, and vice versa. However, they complement each other very well.

Event Sourcing is a design pattern where you store the entire history of state changes as a sequence of immutable, append-only events, rather than just storing the current state.
Because reading and reconstructing state from a series of historical events is too slow for queries, CQRS is utilized to build read-optimized database projections from these events, keeping read operations incredibly fast.

When Should You Use CQRS?

Despite its advantages, CQRS introduces significant complexity to your software architecture. Therefore, it should not be applied to simple projects.

CQRS is highly recommended when:

High Read-to-Write Ratio: Your application has a massive volume of reads but relatively sparse writes (e.g., news portals, e-commerce catalog search, or social media feeds).
Complex Business Domains: The business rules to process state changes are highly intricate, while the read paths require aggregating data from multiple boundaries.
Polyglot Persistence Requirements: You want to leverage different database engines, such as using PostgreSQL for transactions (writes) and Elasticsearch for fuzzy search and indexing (reads).

Avoid CQRS when:

Simple CRUD Applications: If your application is a straightforward admin dashboard that mainly inserts and displays values without complex validation logic.
Strong Consistency is Mandatory: If your domain cannot tolerate any eventual consistency delay under any circumstances (e.g., core bank ledger transfers, although even these can be designed to tolerate latency using compensating transactions).
Team Resource Limits: Managing a distributed, eventually consistent, asynchronous CQRS system requires a deep understanding of message brokers and debugging distributed systems.

FAQ

Do write and read databases have to use different database engines?

No. In the simplest implementation, you can use the same relational database engine (like PostgreSQL) but separate the read and write paths in your code using different database connections, models, and classes.

How do I handle eventual consistency in the user interface (UI)?

You can utilize Optimistic UI updates, where the frontend immediately displays the expected changes before the server confirms the sync. Alternatively, you can use loading states, or design the user flow so that a redirect does not immediately drop the user on the updated page.

Should CQRS be applied to the entire application?

Definitely not. You should only apply CQRS to specific bounded contexts or sub-domains that experience high performance bottlenecks or high business complexity, while leaving the rest of the application under simple CRUD patterns.

What are your thoughts on the CQRS pattern? Is the architectural complexity worth the performance gains? If you have implemented this in your team, share your experience in the comments below!

Table of Contents