CQRS and Event Sourcing

Bertrand Meyer stated the underlying principle in 1988: every method should be either a command (which changes state and returns nothing) or a query (which returns data and changes nothing), but not both. Greg Young applied this principle at the architectural level in 2010, introducing the term CQRS: Command Query Responsibility Segregation.

In CQRS, the system has two distinct models. The command model (write side) handles state changes through commands: PlaceOrder,SubmitVATReturn, CancelReservation. It enforces business rules and invariants. The query model (read side) handles data retrieval optimised for the specific read patterns the system requires.

At the simplest level, CQRS means different code paths in the same service with the same database. Command handlers process writes; query handlers process reads. This alone improves code clarity. The more powerful form uses a dedicated read store, a denormalised database projection optimised for specific query patterns and updated asynchronously from domain events emitted by the write side.

A read model (also called a projection or view model) is a denormalised data structure pre-computed for a specific query pattern. Rather than joining five tables on every request, the read model stores the joined and computed result, updated whenever the underlying data changes.

HMRC's taxpayer account dashboard shows: total VAT owed, breakdown by period, submission history, and upcoming deadlines. In a normalised write model, this requires joining the submissions table, the periods table, the obligations table, and computing aggregates. At 2 million concurrent users, this query load would be unsustainable on the write database.

The read model stores a pre-computed taxpayer summary document, updated each time a VATReturnSubmitted event is published. The query handler reads a single document per user. Latency drops from hundreds of milliseconds to single digits.

The trade-off is eventual consistency. Between the event being published and the read model being updated, the summary may show stale data. For most read patterns this is acceptable. For the user who just submitted a return and refreshes immediately, the system should either show a “processing” state or read recent writes directly from the command model.

Traditional persistence stores current state: a row in the database holds the current order status. When state changes, the row is updated and the previous value is overwritten. History must be maintained separately in an audit log, if it exists at all.

Event sourcing stores the sequence of events that produced the current state as an immutable, append-only log. To determine the current state of order-1042, replay its events from the beginning: OrderCreated,ItemAdded (3 times), PaymentProcessed,OrderShipped. The current state is derived; the event log is the source of truth.

This model provides three properties that traditional persistence cannot. First, full audit history is built into the storage format: every state transition is preserved. Second, temporal queries: “what was the state of this account at 10:00 on 15 March?” is answered by replaying events to that timestamp. Third, projection rebuilding: if a read model becomes corrupted or a new query pattern is needed, replay the event log and rebuild from scratch.

As the event log grows, replaying all events for every state reconstruction becomes slow. Snapshots address this: periodically store a snapshot of the current aggregate state and replay only events since the snapshot. The snapshot is a performance optimisation; the event log remains the source of truth and could reconstruct the state from the beginning if required.

An event store is an append-only database optimised for event streams. Events are organised into streams, each stream representing an aggregate (an order, a tax account, a trading position). Events are written to the stream end with an expected version for optimistic concurrency control: if two processes attempt to append event 101 to a stream that ends at event 100, one will succeed and one will receive a concurrency conflict error.

EventStoreDB (open source, maintained by Event Store Ltd) is purpose-built for event sourcing. It provides: stream-per-aggregate storage, subscriptions for real-time event delivery to projectors, server-side projections for cross-stream queries, and a catch-up subscription mechanism for building read models from any historical point.

PostgreSQL can be used as an event store with a table structured as:(stream_id, position, event_type, data, metadata, created_at). Appends use optimistic locking on position. Reads select all events for a stream ordered by position. This approach trades EventStoreDB's optimised features for operational simplicity if the team already operates PostgreSQL.

Greg Young has stated that CQRS is appropriate in fewer than 10% of bounded contexts in a typical system. Event sourcing applies to an even smaller fraction. Both patterns add significant accidental complexity in exchange for benefits that only materialise in specific scenarios.

CQRS adds operational complexity: separate read and write stores to maintain, event projectors to operate, and eventual consistency to handle in the user interface. These costs are justified when read and write loads are dramatically different, when multiple teams need to evolve read and write models independently, or when HMRC-style regulatory requirements mandate separate read and write optimisations.

Event sourcing adds: event schema management and evolution, snapshot strategy design, projection rebuilding when read models change, and a steeper learning curve for the development team. These costs are justified when full audit history is a core business or regulatory requirement, when temporal queries are needed, or when projections need to be rebuilt for new features. They are not justified for a standard CRUD application where history has no business value.