CQRS: When It Helps and When It's Overkill

In a traditional CRUD app, the same model handles writes and reads: one ORM, one schema, one set of entities. CQRS says: the model for writing is not the model for reading.

The separation

• Write model (command side): enforces business invariants, persists changes
• Read model (query side): denormalized, optimized for specific query patterns
• Can be same DB with different views, or separate DBs with different tech
• Routed through different handlers; different code paths

When CQRS helps

Read/write scale asymmetry

• Reads 100x writes (typical e-commerce)
• Dedicated read models, caching, even different DB tech
• Write side stays simple and consistent

Complex domain logic on writes

• DDD aggregates enforcing invariants
• Decoupling query model lets writes focus on consistency

Diverse read patterns

• UI list view, detail view, search view, analytics view
• One write model feeds many read models
• Each projection optimized for its query

Different scaling needs

• Elasticsearch for full-text search on reads
• Postgres for ACID writes
• ClickHouse for analytics
• Each scales independently

When CQRS is overkill

• Simple CRUD with simple queries; just use a DB
• Strong consistency required between writes and reads; CQRS introduces eventual consistency
• Small team, low traffic; complexity cost outweighs benefit

Relationship to event sourcing

• CQRS is not the same as event sourcing; they combine well
• Event sourcing stores state changes as events
• Projections build read models by replaying events
• Can do CQRS without event sourcing (materialized views, CDC)
• Can do event sourcing without CQRS (rare)

Implementation patterns

Pattern 1: same DB, different models

• One DB, normalized write tables, denormalized read views
• Maintain read view via materialized views, triggers, application updates, or CDC
• Simple; no eventual consistency nightmare

Pattern 2: CQRS with event sourcing

• Write side stores events, not state
• Aggregate rebuilt by replaying events
• Read side builds projections from event stream
• New read shape means new projector; replay events
• Powerful for adding views later without touching write model

Pattern 3: CQRS with separate DBs

• Write to Postgres; read from Elasticsearch
• CDC feeds Elasticsearch; or events drive projections
• Different tech optimized for write vs read needs

Key gotchas

Eventual consistency in UX

• Write updates; event published; projection updated; takes ms to seconds
• User places order, navigates to My Orders; might not appear yet
• Solutions: optimistic UI, read-your-writes cache, return read-model data in command response

Dual-write problem

• Writing to DB and publishing event non-atomically risks divergence
• Outbox pattern solves it: event in same DB transaction, separate publisher drains
• Event sourcing solves it: event IS the write

Read model rebuild

• If projection logic is buggy, delete and replay all events
• At 10M events takes hours; plan for this
• Design projections idempotent so rebuilds are safe

Snapshotting for event sourcing

• Replaying 10K events per command is slow
• Snapshot aggregate state every N events
• Rebuild from latest snapshot plus subsequent events

When to skip CQRS entirely

• Most CRUD apps; don't use CQRS
• Read replicas scale reads without CQRS complexity
• Materialized views give denormalized reads without separate code paths
• CDC feeds search index without full CQRS machinery

The default recommendations

• Most CRUD apps: don't use CQRS
• Complex domains with DDD: consider CQRS
• Need audit log and temporal queries: CQRS + event sourcing
• Read/write scale asymmetry with different tech: CQRS with separate read DB

Tooling

• Axon Framework (JVM) provides CQRS + ES infrastructure
• MediatR in .NET
• Roll-your-own is possible but painful

The strategic answer

• Pattern has real benefits for complex domains and scale asymmetry
• Real costs: complexity, eventual consistency, operational burden
• Don't apply because 'microservices'
• Materialized views and read replicas solve many cases more simply
• Full CQRS + event sourcing for domains where audit and temporal queries justify it