CQRS and Event Sourcing: A Practitioner's Honest Take

Starting With Honest Expectations

CQRS and Event Sourcing (ES) are among the most discussed and most misapplied patterns in modern software architecture. They appear frequently in blog posts, conference talks, and job postings as markers of architectural sophistication. They appear less frequently in production systems that are actually better for having them.

That's not a knock on the patterns. Both CQRS and event sourcing solve real problems elegantly. The issue is that the problems they solve are specific and the complexity they introduce is significant. Applying them to systems that don't have those specific problems is expensive and counterproductive.

This post explains what CQRS and event sourcing actually do, the implementation complexity involved, and the conditions under which that complexity is justified.

CQRS: The Core Idea

Command Query Responsibility Segregation (CQRS) is the principle that reading data and writing data should use different models and potentially different paths through your system.

The term comes from Bertrand Meyer's Command Query Separation (CQS) principle: methods should either perform an action (command) or return data (query), but not both. CQRS applies this at the architectural level: your system has a command side (write operations that change state) and a query side (read operations that return data).

In a simple implementation, this might just mean using different service classes for reads and writes. In a more complete implementation, it means completely separate models: a write model optimized for expressing and validating domain operations, and one or more read models optimized for the specific data access patterns of your UI or API consumers.

Why Would You Want Separate Models?

The value becomes clear when read and write requirements diverge significantly.

Consider an e-commerce order system. Writing an order is a complex domain operation: validate inventory, calculate pricing with promotions, apply tax rules, verify payment method, update inventory reservations. The write model needs to express this business logic clearly and enforce invariants.

Reading orders, however, serves many different purposes. An order history page needs a flat, paginated list of orders with basic status. An analytics dashboard needs aggregated order metrics by date, product category, and geography. A warehouse pick list needs orders grouped by fulfillment center with specific item attributes. A customer service view needs orders with full audit history and communication log.

If you try to serve all of these read patterns from the same model as your write operations, you end up with either a very complex model that serves all purposes poorly, or N-to-1 queries that join data in ways your write model doesn't efficiently support.

CQRS acknowledges this divergence explicitly. The write model is optimized for writes. The read models (there can be multiple) are optimized for their specific consumers.

CQRS Without Event Sourcing

CQRS and event sourcing are often mentioned together, but they're independent patterns. You can implement CQRS without event sourcing:

Commands go through a command handler that executes domain logic and writes to the write store (typically a relational database)
An event or trigger publishes the state change
Read model projections update one or more read stores (denormalized tables, Elasticsearch indexes, a separate database) based on the change
Queries read from the read store directly

This is a significant but tractable implementation. The read stores are eventually consistent with the write store — updates propagate asynchronously.

Event Sourcing: Storing Events Instead of State

Event sourcing takes a fundamentally different approach to persistence. Instead of storing the current state of an entity, you store the sequence of events that produced that state.

An Order entity is not stored as a record with fields like status: "shipped" and total: 149.99. Instead, you store a sequence of events:

OrderCreated { id, customerId, items }
PaymentCaptured { orderId, amount, paymentMethod }
OrderConfirmed { orderId }
ItemShipped { orderId, itemId, trackingNumber }

The current state of the order is derived by replaying these events in sequence — a process called projection or reconstitution. Every state the entity has ever been in is recoverable by replaying the event log up to a given point.

What Event Sourcing Actually Provides

Complete audit history. Every change to every entity is preserved. This is genuinely valuable in domains where you need to answer "what was the state of this account on March 1st at 3pm?" Financial systems, healthcare systems, and compliance-heavy domains benefit from this.

Temporal queries. Query the state of any entity at any point in its history without maintaining separate audit tables.

Event-driven integration. Your event log is a natural source of events for other systems. The events that drive state changes also drive integration.

Debugging and analysis. When something goes wrong, the full event history shows exactly what happened. No need to reconstruct state from current data and logs.

What Event Sourcing Actually Costs

Eventual consistency is unavoidable. Projections (the read models derived from the event stream) update asynchronously. If you write an event and immediately query for the current state, you might read stale data. This is inherently part of the model.

Schema evolution is genuinely hard. Events are immutable records of history. When your domain evolves and event schemas change, you need strategies for handling both old and new event formats. Upcasting (transforming old events to new schemas during replay) adds significant complexity.

Projection management. Every read model is a projection from the event log. When you add a new query requirement, you add a new projection — and potentially need to rebuild it from the full event history. If the event log is years old and has millions of events, this can be a significant operational task.

No simple queries against the write side. You can't simply SELECT * FROM orders WHERE status = 'pending'. Current state exists only in projections, not in the event store directly.

Snapshots. For entities with long event histories, replaying thousands of events to reconstitute state is slow. Snapshots — periodic captures of an entity's current state — address this but add another layer of operational complexity.

When the Complexity Is Justified

CQRS is justified when your system has:

Significantly asymmetric read and write complexity
Multiple read patterns that are hard to serve from a single model
Performance requirements that benefit from optimized, denormalized read stores
Team capacity to manage the eventual consistency and projection complexity

Event sourcing is justified when your system has:

Genuine audit and history requirements — not "nice to have," but critical for compliance, financial accuracy, or regulatory reporting
Domains where time-based queries (state at a point in history) are a real requirement
Event-driven integration where the event log is the natural source of truth for downstream systems

Neither pattern is justified when applied speculatively — "we might need this someday" — or as a marker of architectural sophistication. The complexity is real and ongoing. The benefits are real only when the problem demands them.

A Simpler Alternative for Most Cases

For systems that need some degree of write/read separation without full CQRS and event sourcing: maintain a separate reporting schema in the same database with denormalized tables maintained by triggers or application-level updates. This achieves much of the query performance benefit with a fraction of the complexity.

For audit requirements without event sourcing: temporal tables (supported in SQL Server and some other databases) maintain a complete history of record changes automatically. Much simpler than event sourcing for most audit needs.

Reach for CQRS and event sourcing when the domain genuinely demands them. For most business applications, a well-designed relational schema with appropriate indexing and clear separation of read and write service logic is sufficient.

If you're evaluating whether CQRS or event sourcing is appropriate for your domain, or working through the implementation complexity, I'm happy to dig into the specifics with you.