Play
Patterns

CQRS

CQRS uses one model to change data and a different one to read it, so each side can be shaped and scaled for its own job.

Command Query Responsibility Segregation uses a separate model for commands that change state and for queries that read it. The two can be different classes in one service or different databases.

Use it when reads and writes have different shapes. A checkout writes a normalized order across five tables, while the order history page wants one flat row per order with the product name already in it. A read store built for that page, and scaled apart from the write store, answers in one lookup. Collaborative or task-based screens also gain, since commands can be small and specific and so conflict less.

The cost is a second model to keep in step. When the read store is separate it is eventually consistent, so a user can save an order and not see it for a moment, and the code must handle that. Messaging between the sides brings duplicates and retries. Martin Fowler warns that for most systems CQRS adds risky complexity, and that a plain CRUD design fits many domains better. Start with a Read Replica or a view before you split the model.

Nearest in Quorum#

The game builds the read side without the split model. A Read Replica serves queries from a lagging copy, and Materialized views and denormalization store the answer a page needs. Change data capture feeds a second store from the write log, and the CDC Connector is the Component. Research Denormalization and Change data capture, and read OLTP and OLAP split for the same idea on reports.

References#