In traditional application architecture, we use the same model for reading and writing data. The same entity class, the same database table, the same service methods handle both updates and queries. This works well for many applications, but it creates tension when read and write requirements diverge significantly.

CQRS (Command Query Responsibility Segregation) resolves this tension by separating the read and write sides of an application. Commands handle updates to the system. Queries handle reads. Each side can be optimized independently.

The pattern builds on the event-driven concepts we explored in the previous chapter. Events often serve as the bridge between the write side (which publishes events) and the read side (which consumes events to build query-optimized views).

In this chapter, you will learn:

The Problem CQRS Solves

Imagine a typical e-commerce product catalog. You have one “Product Service” that does everything:

At first, a single service and a single database feels clean:

But as traffic grows, this simplicity turns into tension.

Read-Write Asymmetry

In most real systems, reads massively outnumber writes.

A typical e-commerce pattern looks like this:

Optimizing for one affects the other:

So if you force both read and write traffic through the same model and schema, you end up making compromises in both directions.

Different Requirements

Reads and writes often have fundamentally different needs:

The CQRS Principle

CQRS separates the read model from the write model.

Commands

Commands express intent to change the system:=.

Command Examples:

Characteristics:

Queries

Queries request information without changing state.

Query Examples:

Characteristics:

Separation Levels

CQRS can be applied at different levels of separation.

Level 1: Code separation (same DB)

You separate command logic and query logic in code, but they still share the same database.

This is often the best first step because it delivers benefits without operational complexity.

Level 2: Model separation (different models, same DB)

You keep one database, but you stop pretending that one model fits all use cases.

You might still store both in the same database, but you treat them differently:

Benefits:

Level 3: Database separation (full CQRS)

Now you split storage:

And you synchronize via events or replication.

This is the “classic” CQRS architecture, but it also comes with real operational cost.

Implementing CQRS

Level 1: Code Separation

The simplest form separates command and query handlers in code.

Traditional service (mixed responsibilities)

CQRS-style separation

Benefits:

Limitations:

Level 2: Model Separation

Use different models for reading and writing.

Write model (rich domain)

Read model (flat DTO)

Benefits:

Level 3: Database Separation

Full separation with different databases optimized for each purpose:

Write Database: PostgreSQL, MySQL for ACID transactions and referential integrity.

Read Database: Elasticsearch for search, Redis for caching, DynamoDB for key-value lookups.

Synchronization: Events flow from write side to update read models.

Synchronization Strategies

Once you separate the write database from the read database, you create a new problem:

The system is now correct in two places, and you have to keep both places aligned.

There are three common approaches: event-based (asynchronous), synchronous projection, and hybrid.

Event-Based Synchronization (Asynchronous)

This is the most common CQRS sync approach.

What you get

The cost: eventual consistency

This is the trade-off that powers CQRS at scale.

Synchronous Projection (Strong Consistency)

Sometimes you can’t tolerate lag. In those cases, you update the read model inside the same logical write operation.

Within one transaction boundary:

Why it’s tricky

This approach works only when you can guarantee atomicity across both updates.

Pros

Cons

Synchronous projection is best reserved for critical read models where correctness matters more than throughput.

Hybrid Approaches

Most production systems mix both.

A practical hybrid setup

This gives you strong UX where it matters without forcing every read model into the hot write path.

Read Model Patterns

Synchronization is about moving changes. Read model patterns are about what shape you move them into. The query side is not a copy of the write DB. It’s a set of purpose-built views.

Denormalized Views

Reads often want “pre-joined, display-ready” data.

Materialized Views

Some read queries are expensive by nature: aggregates, group-bys, multi-dimensional stats.

Instead of running this repeatedly:

You store the result:

Then update it when relevant events occur (ProductCreated, ProductDeleted, PriceUpdated, etc.).

Multiple Read Models

This is where CQRS becomes powerful: the same write-side truth can feed many read-side shapes.

Each read model optimized for specific query patterns.

Handling Eventual Consistency

With separate databases synchronized via events, consistency is eventual.

The User Experience Challenge

Strategies

1. Read-Your-Writes

After a successful write, route the user’s next reads to the freshest source.

Common options:

This is a targeted solution: you don’t abandon the read model, you just avoid confusing the user right after a write.

2. Optimistic UI

If you can safely assume the write succeeded, update the UI immediately.

Flow:

This works well when:

3. Polling or Push

After returning success, you can actively wait until the query side catches up.

Options:

This is common for workflows like:

4. Version Tracking

Attach a monotonically increasing version to changes.

This gives you a precise definition of “caught up” without guessing based on time.

When to Use CQRS

Good Fit

Poor Fit

Decision Heuristic

Consider CQRS when:

Avoid CQRS when:

CQRS in Practice

E-Commerce Example

Write Side: PostgreSQL handles all transactions with referential integrity.

Read Side:

Summary

CQRS separates the read and write sides of an application: