Start with the decision#
Use CQRS when commands and queries genuinely need different models, scaling, or security boundaries. Separate intent from presentation; do not split a simple CRUD service merely to add architecture vocabulary.
Mechanism and state flow#
- Express writes as domain commands with validation and invariant enforcement.
- Commit authoritative state and a projection signal atomically, usually through the same transaction or an outbox.
- Build idempotent read projections shaped for concrete query paths.
- Expose projection version or freshness where users can act on stale data.
- Rebuild projections from an authoritative source and version schema changes independently.
Concrete example#
Order entry and operations dashboard
PlaceOrder validates inventory and payment invariants in the write model. An outbox drives a denormalized dashboard grouped by region and fulfillment state. The command response returns the order identity and version without waiting for every dashboard projection.
Architecture consequence: Treat the dashboard as a replaceable, lagging view and keep decisions that require current order state on the command side.
Trade-offs#
| Option | Choose when | Cost or limit |
|---|---|---|
| Shared store, separate models | Read/write code needs separation but one transaction boundary still fits. | Independent scaling and failure isolation remain limited. |
| Separate read store | Query shape or volume justifies dedicated projections. | Eventual consistency, replay, and dual operations are unavoidable. |
| Ordinary CRUD | One model meets the load and domain complexity. | Read and write optimization stay coupled, but the system remains simpler. |
Failure diagnosis#
- Failure
- The command succeeds but the projection consumer is down.
- Impact
- The user refreshes into stale state and may repeat or contradict the command.
- Detection
- Projection checkpoint age trails the write version and user reads expose the lag.
- Mitigation
- Return command identity, make retries idempotent, expose pending state, and replay the durable projection signal.
- Trade-off
- Read-your-write overlays add client and API complexity.
Design checkpoint#
Work the scenario before revealing the checklist
- Name one command invariant and one query projection that differ materially.
- Draw the atomic boundary between write state and projection signal.
- Define how the UI behaves before the projection catches up.
- Describe projection rebuild and schema version rollout.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- What complexity justifies CQRS here?
- Which model is authoritative?
- How is the projection signal committed without a gap?
- Can a stale read trigger a destructive command?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- CQRS patternMicrosoft Azure Architecture Center
- Saga distributed transactions patternMicrosoft Azure Architecture Center
Sources reviewed 2026-09-04. Service limits and product-specific guarantees still require current verification.