When CQRS is overkill

The real cost of CQRS

CQRS is not free. Before applying it, a team should understand exactly what it introduces:

Two models to design, build, and maintain. Every write-side change must be propagated to one or more read models. Each new read model is a new projection to write, test, and operate. Each change to the write-side schema must be evaluated for its effect on every projection.

Eventual consistency where there was none. An async projection means the read model can be stale. This is a correctness concern that must be explicitly communicated, managed, and designed around. Users see data that is not the latest. Some queries that used to be strongly consistent are now eventually consistent.

Projection infrastructure. Async projection requires a mechanism for observing write-side changes: a domain event bus, change-data capture, or an outbox pattern. Each of these has operational overhead — deployments, monitoring, failure handling, dead-letter queues.

More complex debugging. When a user asks “why does my dashboard show the wrong status,” the answer may involve the write model, the projection pipeline, the read model, and the eventual consistency window. The causal chain is longer and harder to trace.

These costs are worth paying when the structural benefit is real. They are waste when applied to problems that do not have genuine read/write asymmetry.

Most CRUD does not need CQRS

A large proportion of application screens are symmetric: the same fields written to the database are the same fields displayed back. An address form writes a name, street, city, and postal code. The edit screen reads those same four fields. The list screen shows those same fields with a filter. No invariant guards the address fields. No complex join is needed. No read/write structural incompatibility exists.

CQRS for this screen adds two models, a projection, and eventual consistency for zero structural benefit. The write model would be CompanyAddress. The read model would be CompanyAddressView. The projection would copy the four fields from the write table to the read table. This is not architecture — it is ceremony.

The heuristic: if the data a screen writes and the data it reads have the same shape and the same fields, CQRS adds complexity without structural benefit.

For the billing platform:

• Company profile edit (name, address, billing contact) — CRUD, no CQRS
• User account settings (email, timezone, notification preferences) — CRUD, no CQRS
• Order approval dashboard (seven-table join, status aggregation, overdue flags) — genuine asymmetry, CQRS justified
• Order submission (credit-limit invariant, line-item invariants, status transitions) — complex write invariants, CQRS justified

Partial and local CQRS

CQRS does not have to be applied to an entire application. The right scope is the bounded context or the domain area where read/write asymmetry actually exists.

In the billing platform, the order management domain has genuine asymmetry: the write side has complex invariants (credit limit, approval workflow, line-item validation), and the read side has complex queries (dashboard, manager pipeline, finance report). CQRS is justified there.

The account management domain is mostly CRUD. Applying CQRS to account management to be “consistent with the order domain” would be cargo-cult architecture — copying the pattern without copying the forces that justify it.

The right answer: apply CQRS locally to the order management domain. Let the account management domain use a simple normalized model with direct reads. The two domains do not need to be architecturally consistent with each other — they need to be appropriate for their own forces.

This is called local CQRS or partial CQRS: CQRS applied selectively where the structural benefit is present, not applied uniformly across the whole system.

CQRS is not event sourcing

The most common misunderstanding about CQRS is conflating it with event sourcing. They are independent patterns that happen to complement each other well. Conflating them doubles the adoption cost.

CQRS splits the write model from the read model. The write side stores current state in a normalized relational table. The read side stores denormalized views. The projection reads the write-side table directly or observes domain events.

Event sourcing (covered in unit 08) stores state as an append-only sequence of events rather than current state. The current state is computed by replaying the event log. Event sourcing is a different write-side storage strategy, independent of how reads are served.

You can have CQRS without event sourcing: the write side is a normalized relational table, the read side is a denormalized projection of that table. This is the most common form of CQRS in production.

You can have event sourcing without CQRS: a service uses an event log as its write store, but serves reads directly from the event log by replaying on demand — no separate read models.

You can have both: the write side is an event log; read models are built by projecting the event log. This combination is powerful but carries the cost of both patterns.