CQRS vs Event Sourcing — are they the same thing?
No. They're orthogonal patterns. People conflate them because they often appear together, but you can use either one without the other.
The two definitions
- CQRS — split application code into separate command (write) and query (read) paths. About code architecture.
- Event Sourcing — store domain events as the source of truth. Current state is reconstructed by replaying events. About storage architecture.
Side-by-side
| CQRS | Event Sourcing | |
|---|---|---|
| What it splits | Write code from read code | Current state from history |
| Storage of current state | One DB, two DBs, anything | Append-only event log |
| Replay capability | No | Yes — rebuild any past state |
| Read model | Optimized DTO from current state | Built by projecting events |
| Implementation effort | Medium (MediatR + handlers) | High (event store + projections + upcasters) |
| Audit trail | Command log, optional | Free, built-in |
| GDPR right-to-be-forgotten | Easy — delete the row | Hard — events are immutable (crypto-shredding workarounds) |
The four combinations
| Combo | When |
|---|---|
| CQRS only | Most common. Want separation of write/read code without the event-store complexity. |
| Event Sourcing only | Rare. Possible — single model handles writes and reads from the event log directly. Performance suffers. |
| CQRS + Event Sourcing | The "full stack" pattern. Write side appends events; read models are projections. Powerful but complex. |
| Neither | Vanilla CRUD. The right choice 90% of the time. |
Why people conflate them
Many tutorials show CQRS with Event Sourcing as the canonical example, because together they tell a coherent story:
Commands → events → event store → projector → read models → queries
But CQRS by itself looks like this:
Commands → entity → DB → query handler → DTO
Far simpler. Same DB. No event store. Most production CQRS systems work this way.
When Event Sourcing pays off
- Regulated domains (banking, insurance, healthcare) where auditors need every state transition
- Disputable transactions (refunds, returns, fraud investigations) — "who changed this when?"
- Multiple read models built from the same events
- Time-travel queries — "what did this customer's profile look like last March?"
When Event Sourcing is over-engineering
- Standard CRUD apps with audit-table-suffices auditing
- Apps where compensating "fix" is fine (don't need to replay events)
- Teams without operational maturity for event store + projections + snapshots
- Apps with strict GDPR delete-on-request requirements
Interview-grade summary
"CQRS is about splitting code into write and read concerns. Event Sourcing is about storing events as the source of truth. They're often shown together but are independent. CQRS alone is the right starting point — gives you 80% of the benefit with much less complexity. Add Event Sourcing only when you have a concrete domain need: regulatory audit, replay capability, or multiple read models from one event stream. Adopting both on day one is a common over-engineering trap."