CQRS Fundamentals

Most systems use the same data model for writing and reading. The order table that receives inserts is the same order table that serves the dashboard. This works until the write requirements and the read requirements diverge — and they always diverge. The write side needs transactional integrity, validation, and business rule enforcement. The read side needs fast queries, denormalized views, and flexible filtering. Optimizing the data model for one degrades the other. CQRS resolves this by maintaining separate models: a command model optimized for writes and a query model optimized for reads.

1. Command Side Commands represent intent to change state: PlaceOrder, CancelSubscription, UpdateAddress. The command model enforces business rules, validates input, and writes events to the event store. It is optimized for consistency and correctness, not query performance. The command model does not serve read queries.
2. Query Side Queries represent requests for data: GetOrderDetails, ListActiveSubscriptions, SearchCustomers. The query model is a denormalized projection built from events — optimized for the specific read patterns the application requires. Multiple query models can coexist, each optimized for a different access pattern.
3. The Synchronization Layer Events flow from the command side to the query side through projections — event handlers that update the read model as events are published. The synchronization is asynchronous, which means the read model is eventually consistent with the write model. The propagation delay is typically milliseconds to seconds.