CQRS

In a normal application you have one model, say an Order entity, and the same code reads it and writes it. CQRS breaks that single model in two. A command is an instruction that changes state, like PlaceOrder or CancelOrder. A query is a request that returns data and changes nothing, like GetOrderHistory. The pattern says: handle these with separate models, and often separate code paths, separate services, and even separate databases.

The reason comes down to a mismatch most systems ignore. Writes need validation, business rules, and consistency. They are usually low volume. Reads are often 10x to 100x more frequent, need to be fast, and want data already shaped for the screen that shows it. Forcing both through one model means you either slow down reads with normalized tables and joins, or you weaken your write model to make reads convenient. CQRS lets each side win on its own terms.

CQRS does not require event sourcing, two databases, or any messaging. The simplest version is just two sets of code in the same service hitting the same database: command handlers that run business logic, and query handlers that run plain optimized SELECTs and skip the domain layer entirely. That alone is valid CQRS.

The write side accepts a command, validates it against business rules, and updates the authoritative data store. This is your source of truth. It stays normalized and consistent because correctness matters more than read speed here.

The read side serves queries from a read model that is optimized for display. In the full version, this read model lives in a separate store: a denormalized table, a document in MongoDB, a search index in Elasticsearch, or a cache in Redis. When the write side changes data, it publishes an event, and a projector listens for that event and updates the read model to match.

That last step introduces the most important property to understand: the read model is updated asynchronously, so it is eventually consistent. There is a small window, usually milliseconds, where a user who just wrote data could query the read side and not see their own change yet. Systems handle this by reading their own writes from the write side, or by showing an optimistic UI update until the projection catches up.

When CQRS is paired with event sourcing, the write side stores the full sequence of events rather than just the current state, and read models are built by replaying those events. The two patterns fit together well, but neither requires the other.

CQRS earns its complexity when read and write loads are very different, when the read shape differs a lot from the write shape, or when many different views need the same underlying data. A reporting dashboard, a product catalog with search and filtering, and a high-traffic feed are all good fits.

The cost is real. You now maintain two models, you accept eventual consistency on reads, and if you add separate stores and projections you take on the operational burden of keeping them in sync and handling projector failures. For a simple CRUD app where reads and writes look nearly identical and traffic is modest, CQRS is over-engineering that buys you nothing.

A common middle ground is to apply CQRS to one busy slice of a system rather than the whole thing. You might run plain CRUD for account settings while using full CQRS with a denormalized read store only for the order history view that gets hammered. The pattern is a tool you apply where the read and write mismatch actually hurts, not a rule you apply everywhere.

Picture an e-commerce checkout. When a customer places an order, the command handler validates stock, charges the card, and writes a normalized order row plus line items into PostgreSQL. That write path enforces every rule and is the source of truth.

Now the customer opens their order history page. That query does not touch the order tables or run six joins. It reads from a denormalized read model, one row per order with the product names, total, and status already flattened in, served from a read replica or a cache. The page loads in a few milliseconds even under heavy traffic.

Keeping the two in sync is the job of a projector. When the order is written, an OrderPlaced event fires, a background worker picks it up, and it upserts the flattened row into the read store. If the worker lags by 50 milliseconds, the history page might briefly miss the newest order, which is an acceptable trade for a read path that scales independently of the write path.