CQRS (Command Query Responsibility Segregation)

Command Query Responsibility Segregation (CQRS) is an architectural pattern that separates the read model (queries) from the write model (commands) of an application. Instead of a single model that handles both creating/updating data and querying it, CQRS uses distinct models optimized for their specific purpose. The write model enforces business rules, validates invariants, and persists changes. The read model is denormalized and optimized for the exact queries the UI needs, often stored in a different database or format than the write model.

CQRS emerges naturally in event-driven systems and pairs especially well with event sourcing. In this combination, the write side appends events to an event store, and one or more read-side projections consume those events to build materialized views. For example, an e-commerce system might write OrderPlaced events to an event store, while separate projections build: a customer's order history view (denormalized for fast lookup), an inventory count view (aggregated for warehouse), and a revenue analytics view (aggregated for dashboards). Each projection can use the most appropriate storage: PostgreSQL for relational queries, Elasticsearch for full-text search, Redis for low-latency lookups.

CQRS introduces significant complexity—maintaining consistency between read and write models, handling projection lag (eventual consistency), managing projection rebuilds, and operating multiple data stores—so it should only be applied where the benefits justify the cost. Good candidates include systems with highly asymmetric read/write ratios (many more reads than writes), complex query requirements that conflict with normalized write models, or domains where different consumers need radically different views of the same data. For simple CRUD applications, CQRS is overkill.