Caching Strategies Explained: Cache-Aside, Write-Through and Write-Back
Caching strategies and their trade-offs: cache-aside, read-through, write-through, write-back and write-around, plus eviction policies, TTLs and invalidation.
Event Sourcing and CQRS: When They’re Worth It
Event sourcing and CQRS explained: storing events instead of state, separate read and write models, audit trails and replay, costs and when to use them.
Key takeaways
- Event sourcing stores every change as an immutable event; current state is rebuilt from the history.
- CQRS separates the write model from one or more read models optimised for queries.
- They add real complexity; use them where audit history, replay or very different read and write needs justify it.
On this page
Event sourcing and CQRS are powerful patterns that often travel together. They solve real problems, and create new ones, so the key question is when they are worth it.
Event sourcing
Instead of storing the current state of an entity, you store the sequence of events that led to it: AccountOpened, MoneyDeposited, MoneyWithdrawn. Current state is calculated by replaying the events.
Benefits:
- A complete, immutable audit trail
- The ability to rebuild state, fix bugs by replaying, or answer new questions about the past
- A natural fit for event-driven systems; logs like Kafka are commonly used alongside (see Kafka vs RabbitMQ vs SQS)
Costs:
- Rebuilding state from long histories needs snapshots
- Changing event formats over time (schema evolution) takes care
- Queries like “all accounts over $1,000” are awkward without extra read models
CQRS
Command Query Responsibility Segregation separates:
- Commands that change state, handled by a write model enforcing business rules
- Queries that read state, served by read models shaped for each screen or API
Read models are updated from events, often asynchronously, so they are eventually consistent with the write model; see the CAP theorem and PACELC.
How they fit together
| Traditional CRUD | Event sourcing + CQRS | |
|---|---|---|
| Stored data | Current state | Event history (plus read models) |
| Audit trail | Added separately | Built in |
| Read performance | Depends on schema | Read models tuned per query |
| Consistency | Immediate | Read side usually eventual |
| Complexity | Low | High |
When they’re worth it
- Domains where history matters: finance, accounting, logistics, compliance
- Complex business rules where modelling commands and events clarifies behaviour
- Read and write workloads that differ dramatically in shape or scale
When to avoid them
- Simple CRUD applications
- Teams without experience of eventual consistency and event versioning
- When a regular database with an audit table would do
Practical tips
- Make event handlers idempotent; events may be delivered more than once (see idempotency keys).
- Version events explicitly.
- Start with one bounded area, not the whole system; our microservices vs monolith framework applies the same caution.
Frequently asked questions
Do I need event sourcing to use CQRS?
No. CQRS can be used with a normal database; the two are independent patterns that often complement each other.
How do you query an event-sourced system?
Through read models or projections, built by processing events into query-friendly views.
Is event sourcing the same as event-driven architecture?
No. Event-driven architecture is about services communicating via events; event sourcing is about storing state as events.
Sources
Every article is edited by a human and checked against our editorial policy. Spotted a mistake? Tell us.
Keep reading
Rate Limiting Algorithms: Token Bucket, Leaky Bucket and Sliding Windows
Rate limiting algorithms compared: fixed window, sliding log, sliding window counter, token bucket and leaky bucket, with code and distributed design tips.
Kafka vs RabbitMQ vs SQS
Kafka, RabbitMQ and Amazon SQS compared: log vs queue models, ordering, replay, throughput, delivery guarantees and operations, and when to use each.