Skip to main content
CQRS & Event Sourcinglesson 4 of 4 · 2 min read

When This Is Overkill

It doubles your moving parts

Hear the uncomfortable truth from teams that have actually shipped this. It roughly doubles the moving parts in your system.

You gain an event store, projections, replay tooling, versioning discipline, and lag in your interface, and every new engineer needs weeks to stop thinking in rows. If your domain does not pay for that, the pattern is a tax with no refund, and reversing it later means migrating your source of truth.

Skip it when your data is genuinely current-state shaped. A content system, an internal admin tool, a settings page, an ordinary product with forms.

Nobody will ever ask for the full history of somebody's notification preferences, and a timestamp column plus a simple audit table covers the rare curiosity.

Skip it too when your team is new to it and the project has a deadline. The first event-sourced system anybody builds contains its own set of lessons, and you want to learn those on a low-stakes service.

When it earns its cost

Watch for the specific signals that it earns its cost. Regulators or auditors require provable history, meaning payments and trading and healthcare. Your business asks questions about time: what did this account look like on March 3, and why did the system decide that.

Several teams want the same facts in different shapes, which is the projection fan-out doing real work. Or your domain is natively a ledger, where the events are the honest model and the current state is the derived thing.

Remember the escape hatch from earlier in this course. These are decisions per component, not identities. An event-sourced payments core behind an ordinary product catalogue is a normal healthy system.

The teams that get burned are the ones who made a religion of it and event-sourced their contact form.

Worked example

Two teams at the same insurance company, same year. Team one event-sources the claims engine: regulators demand complete history, adjusters ask what the claim looked like before Tuesday's amendment, and disputes hinge on when facts were recorded. Eighteen months in, replay has saved them twice from projection bugs and an audit passes on the strength of the event log alone. Team two event-sources the internal tool that manages office equipment requests, because the claims architecture looked impressive. They spend three sprints on event versioning for a system whose hardest query is "who has laptop 214," and onboarding a new hire onto it takes a month. In the year-end review, team two's own retrospective recommends rebuilding as CRUD, an estimated two-week job that keeps getting deferred because the event store is now load-bearing.

CQRS & Event Sourcing: wrapping up

In the real world

  • 01Banking cores and payment ledgers are event sourcing's home turf: an account balance is legally the sum of its postings, and double-entry ledgers have worked this way on paper for centuries.
  • 02Git is a mainstream event-sourced system: the commit history is an immutable log, branches are pointers into it, and a working tree is a projection built by replay.
  • 03Kafka is frequently the backbone for event-sourced and CQRS systems; LinkedIn built it to treat the log as the central abstraction, an idea Jay Kreps laid out in his widely cited log essay.
  • 04EventStoreDB, created by Greg Young, who named and popularized CQRS, is a purpose-built event store with per-stream appends, optimistic concurrency, and replayable subscriptions for projections.
  • 05Nubank, one of the largest digital banks, built its core on Datomic and immutable facts, using history-preserving storage to serve audit and temporal queries across hundreds of millions of accounts.

Questions people ask

Can I use CQRS without event sourcing?

Yes, and most CQRS in production is exactly that. Splitting command handling from query handling, with denormalized read views updated asynchronously, works fine over an ordinary relational database. Event sourcing is a separate decision about making an event log the source of truth. CQRS without event sourcing is common; event sourcing without some form of CQRS is rare, because you need projections to query efficiently anyway.

How do you handle GDPR deletion requests if events are immutable?

The standard technique is crypto-shredding: encrypt each user's personal data inside events with a per-user key, and honor a deletion request by destroying the key. The events remain in the log for integrity, but the personal fields become permanently unreadable. Alternatives include keeping personal data outside the log with references, or rewriting streams, which most teams avoid because it breaks the immutability guarantees everything else relies on.

What happens when an event log gets huge, do reads slow down forever?

Reads for queries do not touch the log at all; they hit projections, which stay fast regardless of log size. The log's size affects entity loading on the write side, solved with snapshots every few hundred events, and full replays, which are batch jobs measured in hours. Storage itself is cheap, and logs compress well, so teams keep full history far longer than intuition suggests.

Quick review

CQRS (Command Query Responsibility Segregation):
write model handles commands (mutations), read model handles queries
Read model is a denormalized projection optimized for the specific query. Can be rebuilt from event log
Event Sourcing:
don't store current state. Store every event that led to it. Current state = replay of events
Benefits of Event Sourcing:
complete audit trail, time-travel debugging, rebuild any projection, replay events to new consumers
Downsides:
eventual consistency between write and read models. Replay takes time on large event logs (use snapshots)
Event Store:
append-only log (Kafka, EventStoreDB). Events are immutable and ordered
Real-world:
bank transaction ledger, git commit history, e-commerce order lifecycle are all event-sourced naturally
the trade-off

High complexity. Event schema evolution is hard. Plan for versioning from day one.

in the room

Audit requirements, complex domain workflows, systems where 'what happened' matters as much as 'what is'.