CQRS (Command Query Responsibility Segregation)

The command model is the sole authority for processing state changes. It encapsulates business logic, validates invariants, and persists events or state transitions. Commands are imperative—they represent an intent to change the system (e.g., PlaceOrder, ReserveInventory).

• Uses a domain model optimized for transactional consistency
• Often leverages Event Sourcing to persist state as an immutable sequence of events
• Commands are typically processed synchronously within a strong consistency boundary
• The command model is the system of record; the query model is derived from it

The query model is a denormalized, read-optimized representation of system state. It is purpose-built to serve specific UI views, reports, or API responses without complex joins or business logic. Queries are side-effect free and never modify state.

• Materialized views are updated asynchronously by consuming events from the write side
• Can use a different database technology (e.g., a search index like Elasticsearch) than the command side
• Enables polyglot persistence—each query model can use the storage engine best suited to its access patterns
• Eliminates object-relational impedance mismatch for reads

CQRS embraces eventual consistency between the command and query models. After a command is successfully processed, there is a non-zero delay before the query model reflects the change. This is not a bug—it is a deliberate trade-off for scalability.

• The read side subscribes to domain events published by the write side
• Lag is typically measured in milliseconds for well-tuned systems
• Requires UI strategies to manage stale reads, such as optimistic UI updates or polling
• Contrasts with ACID transactions that guarantee immediate consistency across all views

Because reads and writes are physically separated, each side can be scaled independently based on its unique load profile. Read-heavy systems (common in e-commerce) can scale out query nodes aggressively without touching the write side.

• The query side can use read replicas, CDNs, or distributed caches
• The command side can be scaled vertically for write throughput or partitioned by aggregate ID
• Different rate-limiting, circuit-breaking, and timeout policies apply to each side
• Enables cost optimization by right-sizing infrastructure per workload

CQRS commands are not CRUD operations. They represent business tasks expressed in the ubiquitous language of the domain. Instead of UpdateCustomerAddress, the command is RelocateCustomer with intent-rich parameters.

• Commands capture the why behind a state change, not just the what
• Enables a complete audit trail when combined with Event Sourcing
• Prevents anemic domain models where logic leaks into services
• Aligns directly with Domain-Driven Design aggregates and bounded contexts

CQRS enforces a strict separation between the logic that mutates state and the logic that presents state. This prevents read-model pollution—where query concerns leak into the domain model through eager loading, DTO projections, or complex ORM mappings.

• The command side focuses purely on invariants, validation, and business rules
• The query side focuses purely on data shaping, filtering, and presentation
• Each side can be developed, tested, and deployed by different teams
• Reduces cognitive load by eliminating the need for a single unified model

Instead of storing just the current state, Event Sourcing persists every state-changing event as an immutable append-only log. This log becomes the single source of truth. When combined with CQRS, the event store acts as the write model, while projections built from those events serve as optimized read models. This pairing provides a complete audit trail and allows you to reconstruct any past state by replaying events.

A Projection is a read-optimized view derived from the write model's events or state. In a CQRS system, projections are the 'Q' side. They denormalize and pre-compute data for specific query patterns. For example, a CustomerOrderSummary projection might combine data from Customer, Order, and Payment aggregates into a single document, enabling sub-millisecond reads without complex joins.

CQRS systems often embrace Eventual Consistency between the write and read sides. After a command updates the write model, there is a non-zero delay before the corresponding read projections are updated. This trade-off is accepted to gain massive scalability and availability. The system guarantees that if no new updates are made, all replicas will eventually converge to the same state.

CQRS is a natural architectural fit for Domain-Driven Design. DDD's Bounded Contexts provide clear boundaries for separating command and query responsibilities. The Aggregate pattern in DDD defines transactional consistency boundaries for commands, while dedicated Read Models handle queries. This alignment ensures the system's architecture directly reflects the business domain's mental model.

A Materialized View is a database object that stores the pre-computed results of a query. In CQRS, materialized views are the physical instantiation of read-side projections. Unlike standard views that execute the query on every access, materialized views cache the result set. They are updated either synchronously within the command transaction or asynchronously via event handlers, trading data freshness for query speed.

A Saga manages long-lived, distributed transactions across multiple services. In a CQRS architecture, a saga listens to domain events and orchestrates workflows by dispatching new commands. For instance, an OrderSaga might listen for an OrderPlaced event, reserve inventory via a command, and handle compensation commands if payment fails. This ensures data consistency across aggregates without distributed locks.