CQRS
Command Query Responsibility Segregation (CQRS) is a software architecture pattern that separates read and write operations into different models. Commands change state (create, update, delete), while queries retrieve data. Each side can be optimised independently: writes might use a normalised relational database for consistency, while reads might use denormalised views or search indexes for performance. For non-technical readers, CQRS recognises that reading data and changing data are fundamentally different activities with different requirements. Most applications read far more than they write, and users expect reads to be fast. By separating these concerns, systems can optimise each side appropriately. The write side ensures data is correct; the read side ensures data is fast to retrieve. CQRS is often combined with Event Sourcing, where changes are stored as a sequence of events rather than overwriting current state. However, CQRS can be applied independently and doesn't require Event Sourcing.
Official WebsiteWhen to use CQRS
Use CQRS when read and write workloads have significantly different requirements, when you need to scale reads and writes independently, or when complex queries are slowing down a system. It's valuable for applications with high read-to-write ratios, complex reporting needs, or collaborative domains where multiple views of the same data are required.
CQRS adds complexity, so it's not appropriate for simple CRUD applications or when a single database model serves both needs adequately.
Why choose CQRS?
Teams choose CQRS when simpler architectures create bottlenecks. Separating read and write models allows each to evolve independently, use appropriate storage technologies, and scale based on actual demand. The pattern can dramatically improve query performance and simplify complex read requirements. It also provides natural boundaries for team ownership.