The Architecture of the CQRS Pattern

CQRS (Command Query Responsibility Segregation) works by splitting one object model into two: a write model that only accepts commands and enforces business invariants, and a read model that only answers queries from a shape pre-optimized for display — so each side can use its own data structures, its own store, and scale independently, at the cost that the two sides no longer share a single transaction.

The two models are not the same object with two method sets

The point people miss is that the command model and the query model describe the same domain with different data structures. The write side is normalized and rule-heavy: it validates, checks invariants, and mutates state. The read side is denormalized and dumb: it stores exactly the rows a screen needs so a query is a single indexed lookup with no joins and no logic.

• Command side. Handles OpenAccount, Deposit, Withdraw. Rejects a withdrawal that would overdraw. Its storage is optimized for correctness and concurrency control, not for reporting.
• Query side. Handles GetBalance, GetMonthlyStatement. It never runs a business rule; it returns a row that was pre-computed when a write happened.

Because the two sides have different shapes, they can eventually live in different databases — even different kinds of database (a relational write store, an Elasticsearch or Redis read store). That is the real payoff, and also where the hard problems begin.

Worked trace: a bank account with an append-only event store

This is where CQRS stops being a diagram. Take account ACC-42. On the write side we do not store a mutable balance column. We store the facts that happened, each with a monotonically increasing sequence number, in an append-only log (this is Event Sourcing — the write model as a stream of events). To handle a command, the aggregate is rebuilt by replaying its events, the rule is checked, and — only if it passes — a new event is appended. A separate projector consumes those events in order and updates the read view.

Read carefully what each side owns. The command side never trusts the read view for its rule check in step 4 — it replays the authoritative event stream and computes 300 itself, then refuses the overdraft. The read view is a cache of truth, updated after the fact by the projector; it is never the thing that enforces "you can't overdraw."

Why the two sides can drift, and why it is the whole difficulty

The moment the read view lives in a different store from the event log, there is no cross-model atomic transaction. Appending seq 3 and updating the read view to 300 are two operations in two systems. Whatever bridges them (a message bus, a poller) is asynchronous, so:

• Eventual consistency. Between the append and the projection, a GetBalance can still return 500. The write is durable; the read is stale for a window of milliseconds to seconds.
• Out-of-order delivery. If the bus delivers seq 3 (withdraw 200) before seq 2 (deposit 500), a naive projector would apply -200 to a balance of 0. The sequence number is the defense: the projector tracks "last applied = N" and buffers or rejects anything that is not N+1.
• Event loss / duplication. At-least-once buses can drop or redeliver. Projections must be idempotent (keyed by seq), and you need to detect gaps.

Because the log is the source of truth, all of these are recoverable: if the read store is corrupted or you invent a new view, you replay events 1..N and rebuild it. The same log doubles as a complete, tamper-evident audit trail — every state the account was ever in is reconstructable.

Pitfalls

• The dual-write trap. Committing to the write DB and then publishing the event as two separate calls is a bug: crash in between and the state changed but no one was told, so the read model diverges forever. Fix: make the event store the commit (Event Sourcing), or use a transactional outbox — write the event to an outbox row in the same DB transaction, and a relay publishes it. Never a raw "save, then send."
• Assuming read-your-writes. A UI that POSTs a change then immediately GETs the list will show stale data during the projection lag. Handle it explicitly: return the new state from the command directly, poll, or show an optimistic pending state — do not pretend the read is instant.
• Unbounded replay. Rebuilding an account with 2 million events by replaying all of them is slow. Real systems add snapshots (store the aggregate state at seq N, replay only N+1 onward).
• Event schema versioning. Events are immutable and kept forever, so you can never "migrate" them like a table. A MoneyDeposited written in 2021 must still deserialize in 2026. You need upcasters / versioned event types from day one.
• Non-idempotent projectors. At-least-once buses redeliver. If applying seq 2 twice adds 500 twice, your read balance is wrong. Track last-applied seq per stream and skip duplicates.
• CQRS everywhere. Splitting a simple CRUD entity into two models plus a bus buys you nothing but two stores to keep in sync. It is the single most common CQRS mistake — over-application.

When to use it, when not — and against what

CQRS is a spectrum, not a switch. You can adopt just the model split (Step 1), then separate stores (Step 2), then Event Sourcing — each step adds power and cost. Decide per bounded context, never globally.

Concrete signals that point here: reads and writes have wildly different shapes or load ratios (e.g. 1 write : 10,000 reads); the read side needs a different store type (full-text search, graph, cache) than the write side; the write side has rich, invariant-heavy domain logic; or the business needs an audit log / temporal queries ("what was the balance on March 1?") that a mutable table cannot answer.

Trade-offs versus the alternatives

• vs. single-model CRUD (one model, one table). CRUD gives you strong read-after-write consistency, one store, and trivial mental model — for free. CQRS costs you eventual consistency, a second store, a bus, and far more moving parts. Choose CRUD when reads and writes share a shape and load is modest; choose CQRS only when the read and write workloads genuinely diverge.
• vs. read replicas / materialized views. These scale reads and even give a denormalized shape without a second codebase model — the database replicates for you, and consistency lag is managed by the engine. You gain read throughput cheaply but the read data stays tied to the write schema and engine. Prefer replicas/materialized views when you want read scaling but not a different store type or a hand-written projector; prefer full CQRS when the read store must be a different technology or the read shape must fully decouple from the write schema.
• vs. CQRS without Event Sourcing. You can keep separate read/write models but store the write side as normal mutable rows, projecting via change events. You avoid replay cost, snapshots, and event-versioning pain — but you lose the free audit trail, the ability to rebuild arbitrary new views, and the ordering guarantee the log provides. Add Event Sourcing only when audit, replay-to-rebuild, or temporal queries are actual requirements.

Rule of thumb: as the source page put it, this is suitable only if the application's non-functional requirements demand such an intricate solution. Start with CRUD; move one context to CQRS when a measured read/write divergence forces it; reach for Event Sourcing last.

Takeaways

• CQRS = two models of the same domain: a rule-enforcing write model and a query-optimized read model, which can eventually live in separate (even different-kind) stores.
• Separate stores mean no cross-model atomic transaction, so reads are eventually consistent — plan for lag, out-of-order delivery, and duplicates instead of pretending they don't happen.
• With Event Sourcing the append-only log is the source of truth: rebuild any read view by replay, and get a full audit trail for free — at the cost of snapshots, idempotent projectors, and event versioning.
• It is a graduated cost. Default to CRUD; adopt CQRS per context when read/write workloads truly diverge; add Event Sourcing only when audit or replay is a real requirement.

Re-authored and deepened for this guide. Synthesizes Greg Young's original CQRS/Event Sourcing talks and papers; Martin Fowler's articles on CQRS, Event Sourcing, and the Materialized View pattern (martinfowler.com); Microsoft's Azure Architecture Center CQRS and Transactional Outbox guidance; Chris Richardson, Microservices Patterns (Event Sourcing, Transactional Outbox); and Vaughn Vernon, Implementing Domain-Driven Design. The bank-account trace, sequence-ordering and dual-write failure analysis, and the CRUD / read-replica / no-ES trade-off framing were written for this page.