Event Sourcing
What is it?
Event sourcing stores all changes to data as an ordered log of events, rather than just keeping the latest state.
Explain like I'm 5
Why was it created?
Storing only current state loses history and the 'why' behind it. Event sourcing was adopted to keep a complete, replayable record of what happened.
Where is it used?
- Audit-heavy systems (finance)
- Event-driven architectures
- Systems needing full history
- CQRS read models
Why should developers care?
It enables powerful auditing and time-travel, and pairs with CQRS in advanced systems, making it relevant for senior architecture.
How does it work?
Every change is recorded as an immutable event appended to a log. Current state is derived by replaying events from the start (often with periodic snapshots for speed). New read models can be built by replaying the same events.
Real-world example
A bank account stores events like 'deposited $100' and 'withdrew $40'; the balance is computed by replaying them, and the full history is always available.
Common use cases
- Complete audit trails
- Rebuilding state or new views
- Debugging via history
- Event-driven integration
Advantages
- Full history and audit trail
- Can rebuild or add new views
- Natural fit for event-driven systems
- Time-travel debugging
Disadvantages
- Complex to implement
- Event schema changes are tricky
- Replaying can be slow without snapshots
- Eventual consistency
When should you use it?
When history, auditability, or rebuildable views are genuinely valuable.
When should you avoid it?
For simple apps where storing current state is plenty — the complexity isn't worth it.
Alternatives
Related terms
Interview questions
Beginner
- What does event sourcing store?
- How is current state obtained?
Intermediate
- Why use snapshots?
- What are the benefits of a full event log?
Senior
- How do you handle event schema evolution?
- How does event sourcing pair with CQRS?
Common misconceptions
- "Event sourcing is just logging" — the event log is the source of truth, not a side record.
- "You always need event sourcing for audit" — a simpler audit log often suffices without full event sourcing.
Fun facts
- State is a derived view; the event log is the real source of truth.
- Snapshots store periodic state so you don't replay from the very beginning every time.
Timeline
- 2010s — Event sourcing popularized with CQRS and DDD
Learning resources
Quick summary
Event sourcing records every change as an immutable event log and derives state by replaying it, giving full history at the cost of complexity.
Cheat sheet
- Store events, not just current state
- Replay to derive state
- Full audit + rebuildable views
- Complex; snapshots speed replay