Most applications start with one data model for everything. The same tables, objects, and APIs are used to create data, update data, and read data back.

That is usually the right place to start. But as a system grows, reads and writes can begin to want very different things.

Writes need to protect correctness. They validate input, check permissions, enforce business rules, and keep the system in a valid state.

Reads need to be fast and convenient. A product page, search result, dashboard, or recommendation feed often wants data in a shape that is easy to display, not necessarily the same shape used for safe writes.

CQRS stands for Command Query Responsibility Segregation. The name sounds heavier than the idea:

CQRS separates those responsibilities so each side can be designed for its own job.

The trade-off is complexity. CQRS adds more code, more concepts, and sometimes more infrastructure. Use it when it solves a real problem. Do not use it just because it sounds architectural.

This chapter explains commands, queries, read models, write models, projection, read delay, how CQRS relates to event sourcing, and when CQRS helps instead of just adding work.