Implement CQRS Architecture

A guide for implementing CQRS (Command Query Responsibility Segregation): separating a system's write model (commands) from its read model (queries) so each can be optimized and scaled independently. Covers identifying which workloads actually need separate read and write handling, defining command and query models with clear boundaries, implementing read-model projections and keeping them synchronized with the write side, and validating performance, recovery, and failure modes before relying on the pattern in production.

Use when read and write concerns need to scale independently, when building an event-sourced system, when query scenarios are complex enough to need a purpose-built read model, when read and write need genuinely different data shapes, or when reporting needs high performance that a single shared model can't deliver. Do not use it when the domain is simple enough that plain CRUD is sufficient, when the system cannot operate separate read and write models, or when strong immediate consistency is required everywhere - CQRS read models are typically eventually consistent.

Input is a description of the domain's read and write workloads and their consistency requirements. Output is a command and query model boundary definition, a read-model projection and synchronization design, and a validation plan covering performance, recovery, and failure modes. For detailed patterns and templates, it points to resources/implementation-playbook.md.

References its own companion resource, resources/implementation-playbook.md, for detailed CQRS patterns and templates beyond this overview.

Architects and backend engineers deciding whether and how to split read and write models for a system under real scaling or reporting pressure, not teams looking for a default architecture for a simple CRUD app.