Architecture Patterns
Also known as: Command Query Responsibility Segregation
A pattern that separates the model used for writing data (commands) from the model used for reading data (queries), allowing each to be optimized independently.
CQRS — Command Query Responsibility Segregation — is the practice of using different models for writing and reading data. Commands change state and have a write-optimized model (often normalized, transactional). Queries return data and can use a separate read model (often denormalized, materialized for the specific shape the UI needs). Reads and writes can use different storage technologies entirely.
The payoff is that each side can be optimized in isolation. Writes can stay in a fully normalized SQL database with strong constraints, while reads are served from a denormalized NoSQL store, an Elasticsearch index, or a precomputed cache. Each read shape is tailored to its consumer.
CQRS is often paired with event sourcing: writes produce events that update the read models asynchronously. This decouples them in time and space and naturally supports eventual consistency. CQRS is overkill for most CRUD apps but invaluable when read and write workloads have very different shapes or scale requirements.
Use CQRS when the read and write workloads have radically different scale, shape, or performance requirements — typically high-traffic systems with rich query needs.
CQRS doubles the number of models, introduces eventual consistency between writes and the read view, and adds significant complexity. Do not adopt it for ordinary CRUD applications.
An architectural style where services communicate primarily by emitting and reacting to events, rather than calling each other directly.
Intentionally duplicating data across tables to avoid expensive joins and improve read performance, at the cost of write complexity.
An architectural style that structures an application as a collection of small, independently deployable services, each responsible for a specific business capability.
A single deployable application containing all features and logic, sharing one codebase, one database, and one deployment unit.
A single entry point that routes external requests to internal services, handling concerns like authentication, rate limiting, and request transformation in one place.
A dedicated infrastructure layer that handles service-to-service communication in a microservices architecture — encryption, retries, observability, traffic shaping — outside application code.