Event sourcing and CQRS: what they buy and what they cost

What it is

With event sourcing, the system of record is an append-only log of domain events ("ArticleCreated", "ProposalAccepted"); current state is a projection built by replaying the log. Command Query Responsibility Segregation (CQRS) uses different models for updating and reading, typically a normalised write model and denormalised read models updated from the events.

Why it matters

The event log is a complete audit trail and allows new read models to be built retroactively. Read models can be shaped for each query. The costs are real: eventual consistency between write and read sides, schema evolution of events, replay time, and a mental model that most teams have not practised.

How to apply

• Use event sourcing where the history is itself a requirement (accounting, audit, collaborative editing) and where events are the natural language of the domain.
• Keep CQRS local: one bounded context, one team, explicit projections with rebuild scripts.
• Version events from the start and write upcasters for old versions.
• For most CRUD systems, a single relational model with a modest change log (as this wiki keeps for thirty days) is simpler and sufficient.

Pitfalls

Treating the event log as a message bus for other systems. Replaying millions of events on every start without snapshots. Adopting the pattern for a domain whose only requirement is "store and retrieve".