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.

Architecturechapter 3 of 5 · 4 lessons

CQRS & Event Sourcing

Separate read and write models; store state as an ordered log of events instead of current values.

← All chapters View in cheatsheet

Your seller dashboard shows order counts, revenue this month, and top products. Building it takes a nine-table join that runs for 4 seconds, and sellers open it constantly.

The tables are not wrong. They are shaped for taking orders safely, one at a time, with the rules enforced. That is the opposite of what a dashboard wants.

Keep a second copy shaped like the dashboard, updated as orders happen, and the page becomes a single row lookup. That is one idea.

The other, larger idea is to stop storing where things stand and store what happened instead, as a list you only ever add to. These two get sold as a package and they are separate, and one of them roughly doubles the moving parts in your system.

Lessons

4 in this chapter

Splitting Reads from WritesCommands change state through one model. Queries read from another, shaped for the screen.2 min
The Event Log as the Source of TruthStore what happened, not what is. Current state becomes a computed result.2 min
Projections and ReplayEvery read view is a fold over the log, which means every read view is rebuildable.3 min
When This Is OverkillMost CRUD apps need none of this. Know the signals that say otherwise.2 min