CQRS: Separate Models for Reading and Writing Data

Why it exists

In complex enterprise systems, a single data model for both reading and writing can create bottlenecks. As complexity grows, this unified model struggles with scalability, maintainability, and performance, as the needs of write operations (consistency, validation) often conflict with read operations (speed, availability).

The mental model

Think of a restaurant's operations. The kitchen is the 'write side' (Commands). It follows strict recipes and procedures to change raw ingredients into a finished dish, optimized for correctness. The menu is the 'read side' (Queries). It's a simplified, easy-to-scan representation of what's available, optimized for customers to quickly make a decision. The kitchen and the menu are two separate systems for two different jobs.

How it works

CQRS routes user intentions to one of two paths. If the intent is to change data, it's a Command, like UpdateUserAddress. This is sent to the write model, which contains the business logic to validate and execute the change, often in a transactional database. If the intent is to retrieve data, it's a Query, like GetUserProfile. This is sent to the read model, a data representation optimized for fast lookups, like a denormalized cache. The read model is updated from the write model, often asynchronously via events, allowing each side to scale independently.

When to use it

Use CQRS in systems with demanding, asymmetrical workloads. For example, an analytics platform that ingests millions of events per second (high writes) but serves complex aggregated dashboards (complex reads). It's also beneficial in collaborative domains where multiple users act on the same data concurrently.

When not to use it

Avoid CQRS for simple CRUD-based applications. The added architectural complexity of managing two separate models, handling data synchronization, and dealing with eventual consistency is often unnecessary overhead. If your read and write patterns are simple and balanced, a traditional approach is easier to maintain.

One canonical example

A stock trading platform. A PlaceBuyOrder command is sent to the write side. It undergoes rigorous validation and records the transaction in a highly consistent database. Meanwhile, to display the live stock ticker to millions of users, the read side serves data from a massively scalable, in-memory cache. This ensures high read volume doesn't slow down critical order processing. A key footgun is integrating cross-cutting concerns like logging directly into this business logic, which creates tight coupling and negates the benefits of separation.