Command Query Responsibility Segregation (CQRS) splits the model that changes data from the model that reads it. Event sourcing stores state as an append-only sequence of events that can be replayed to rebuild any state at any time.
Neither pattern is a default. Both are tools for specific pressure points: complex reads on top of a write model, audit requirements, or a domain where the history itself is valuable.
What CQRS solves
In a classic system, reads and writes share one model, so a query-heavy feature can force compromises into your write model. CQRS lets each side be optimized and scaled independently.
- Separate read models can be denormalized for fast queries.
- Writes stay small and focused on commands.
- Read and write sides scale independently.
What event sourcing adds
Event sourcing records facts — "order placed", "price changed" — as immutable events. You can rebuild projections, debug by replaying history, and answer any historical question.
Start with CQRS only if reads and writes genuinely conflict. Add event sourcing only if the event history has real business value. Both add significant complexity.
The practical path
Try query optimization on your existing model first. Introduce CQRS for one bounded context, not the whole system. Add event sourcing when you need a reliable audit trail or time-travel debugging.
CQRS and event sourcing FAQ
Can I use CQRS without event sourcing?
Yes, and this is the recommended path. The two patterns are independent. Most teams that need CQRS do not need event sourcing.
What are the downsides of event sourcing?
Eventual consistency, event schema evolution, replay complexity, and a steeper learning curve. It also makes naive CRUD edits, like directly fixing a row, much harder.
