CQRS

The Library Analogy

Imagine a massive, bustling city library.

If they used a traditional database model (CRUD), everyone would wait in the same line at the front desk. Whether you want to return a book (writing data) or ask if a specific book is in stock (reading data), you talk to the exact same librarian checking the exact same computer system. If 1,000 people want to search the catalog, the line stalls, and nobody can return their books.

Instead, a well-run library uses a pattern like CQRS.

They have a dedicated Returns Desk where you drop off books (Commands/Writes). Completely separate from that, they have rows of computers where anyone can search the catalog at any time (Queries/Reads). The search computers don't process returns, and the return desk doesn't do catalog searches.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Commands go to the Write Service, which writes to SQL and fires an event. The event syncs the Read Model (NoSQL) asynchronously. Queries hit the Read Service, which returns pre-built data at low latency. The write path and read path never touch the same database.

1 / 10.5×1×2×3×Playground

Commands go to the Write Service, which writes to SQL and fires an event. The event syncs the pre-built Read Model asynchronously. Queries hit the Read Service and return data at low latency.

What is CQRS?

CQRS stands for Command Query Responsibility Segregation.

It is a system design pattern that dictates that the data structures and APIs used to update data (Commands) should be strictly separated from the data structures and APIs used to read data (Queries).

The Problem it Solves

In traditional systems, you often use the exact same data model to write to a database as you do to read from it.

But reads and writes usually have completely different requirements.

• Writes (Commands) need to validate complex business rules, ensure data integrity, and handle transaction locks.
• Reads (Queries) usually just want data fast, often requiring complex joins across multiple tables to present a view to the user.

When a system scales, trying to make a single database model fast for both complex writes and heavy reads becomes impossible.

The CQRS Solution

CQRS splits the system in two:

1. The Write Model (Commands): Handles actions that change state (CreateUser, UpdateOrder). It's optimized for validation and fast writes.
2. The Read Model (Queries): Handles actions that return data (GetUserDetails, ListOrders). It's heavily denormalized. Instead of complex SQL joins, data is stored exactly how the frontend needs to display it (often in a fast NoSQL database or a search index like Elasticsearch).

Real-World Example: Social Media Feeds

Think about Facebook or X (formerly Twitter).

The ratio of Reads to Writes is astronomical. For every one person who writes a post (Command), millions of people might read it (Query).

If they used the same database for both, the system would collapse. Instead, they use CQRS.

• When you post a tweet, it goes to a Write service.
• In the background, an event is fired that updates the Read databases of all your followers.
• When your followers open their app, they aren't running complex SQL queries against a central database. They are querying highly optimized Read stores that simply serve up their pre-built feed.

The Catch: Eventual Consistency

Because the Write database and the Read database are separate, they have to be synced. Usually, when the Write model saves a change, it publishes an event. The Read model listens to this event and updates itself.

This introduces Eventual Consistency. There is a tiny delay (milliseconds to seconds) between when data is written and when it appears in the read database.

Summary

CQRS separates the operations that mutate data from the operations that read data. By decoupling the write model from the read model, you can scale them independently and optimize each for their specific tasks. The cost is complexity and eventual consistency. It is the right pattern for high-traffic systems where reads vastly outnumber writes.