CQRS Explained: Why Separating Reads from Writes Scales

Most applications start with one database and one model. The same tables, the same ORM entities, and the same service layer handle every request, whether it's a user placing an order or a thousand users browsing the catalog.

This works well for a long time. But as traffic grows, the cracks start to show, especially in apps like e-commerce where reads outnumber writes by 100 to 1 or more.

Product pages need denormalized, fast, search-friendly data.
Checkout needs normalized, transactional, strictly validated data.
Heavy read queries (joins across five tables) compete with writes for the same database resources.
Every schema change risks breaking both sides.

One model is being asked to serve two very different jobs. That is the problem CQRS is designed to solve.

What is CQRS?

CQRS stands for Command Query Responsibility Segregation. The idea is simple: split your system into two sides, one that changes data and one that reads it.

Command – an intent to change state. It returns no data (or just an acknowledgement). Examples: PlaceOrder, UpdateStock, CancelOrder.
Query – a request for data. It never changes state. Examples: GetProductDetails, ListOrdersForUser.

In a traditional setup, both go through the same model. In CQRS, they get separate modules, and often separate databases.

1┌──────────────┐        ┌──────────────┐
2 Command ──▶│  Write Model │───────▶│   Write DB   │
3            │ (validation, │        │ (PostgreSQL) │
4            │  business    │        └──────┬───────┘
5            │  rules)      │               │ publishes events
6            └──────────────┘               ▼
7                                    ┌──────────────┐
8                                    │ Event Broker │
9                                    │ (Kafka/SQS)  │
10                                    └──────┬───────┘
11                                           │ consumes events
12            ┌──────────────┐        ┌──────▼───────┐
13 Query  ───▶│  Read Model  │◀───────│   Read DB    │
14            │ (simple,     │        │  (MongoDB)   │
15            │  no rules)   │        └──────────────┘
16            └──────────────┘

Why separate databases?

Because reads and writes want different things:

Write side – Goal: correctness and integrity. Data is normalized. Typically PostgreSQL or MySQL. Scales vertically, with careful sharding.
Read side – Goal: speed and flexibility. Data is denormalized and pre-joined. Typically MongoDB, Elasticsearch, or Redis. Scales horizontally and can be replicated globally.

The write side can stay strict with transactions, constraints, and validation. The read side can store data exactly the way the UI needs it, with no joins at query time, and scale independently across regions.

How the Two Sides Stay in Sync

The moment you have two databases, a new question appears: how does the read DB learn about changes made in the write DB?

The most common answer is events. If you've read my post on Event-Driven Architecture, this will feel familiar.

A command arrives and the write model validates it.
The write model saves the change to the write DB.
It then publishes an event (e.g. OrderPlaced) to a broker like Kafka, SQS, or SNS.
A projector on the read side consumes the event and updates the read DB.

Take an e-commerce example. A customer clicks "Place Order":

The write side checks stock, validates the payment, and saves the order in PostgreSQL.
It then announces, "Order #123 was placed," by publishing an OrderPlaced event.
The read side hears the event and updates its own copy of the data, say a ready-made "My Orders" view in MongoDB.
When the customer opens "My Orders", the read side returns that view directly. It does no joins and runs no business rules.

The two sides never talk to each other directly. They only share events, which is what keeps them independent.

The catch: eventual consistency

Events take time to travel. Between the write and the projector finishing, the read DB is stale. This is called eventual consistency: the two stores will agree, just not instantly.

Picture this on an e-commerce site: a user places an order, gets redirected to "My Orders", and the new order isn't there yet. To them it looks like the order was lost.

Common ways to deal with it:

Optimistic UI – show the new order from the command response while the read side catches up.
Read-your-own-writes – route that user's next read to the write DB briefly.
Idempotent projectors – brokers can deliver an event more than once, so applying the same event twice must be safe.
Rebuild when needed – the write DB is the source of truth, so a broken or outdated read DB can always be rebuilt from it.

When to Use CQRS (and When Not To)

CQRS is powerful, but it is not a default choice. It adds real complexity, so it has to earn its place.

You probably don't need CQRS if:

Your app serves roughly 100K to 1M users. A well-indexed PostgreSQL, read replicas, and a cache (Redis) handle this scale comfortably.
Your reads and writes have a similar data shape.
It's mostly simple CRUD with modest traffic.
Your team is small and can't afford to operate extra infrastructure.

At this size, the operational cost of two databases, a broker, and projectors is larger than the problem it solves.

CQRS starts to make sense when:

You operate at global scale, with read traffic spread across regions.
The app is read-heavy and data-heavy, like e-commerce, with catalogs, search, recommendations, and order history, while writes (checkout, inventory) need strict consistency.
Reads need a very different shape than writes (search, aggregates, dashboards).
Read and write sides need to scale and be deployed independently.

The trade-offs

Two databases to run – more infrastructure, cost, and monitoring.
Sync lag – eventual consistency leaks into UX and business logic.
Harder debugging – a bug could be in the command, the event, the broker, or the projector.
More code – separate models, handlers, and projections for the same feature.

Closing Thoughts

CQRS is a simple idea (separate reads from writes) with big consequences. It lets each side use the database and data shape it's best at, and it scales well for global, read-heavy systems like e-commerce. The price is eventual consistency and a more complex system.

A good rule of thumb:

Start with one database. Add caching and read replicas first. Reach for CQRS only when the read and write workloads have clearly outgrown a shared model.

If you're under a million users, you likely don't need it yet. But understanding the pattern now will make the decision much easier when your system grows into it.