Event Sourcing
Store state as an immutable log of events rather than the current snapshot — rebuild state by replaying events.
★★★★★3/5Inside a codebase — classes, modules, files
Interactive visualization
LiveEvent Log
append-only · immutableAppend your first event below.
Current State
How it works
In Event Sourcing, every state change is persisted as an immutable event in an append-only log. Current state is derived by replaying all events from the beginning (or from a snapshot + later events).
This gives you a full audit trail for free, the ability to replay history to correct bugs, and a natural integration point for CQRS. The event log IS the source of truth.
The main challenge is handling event schema evolution and ensuring replay performance as logs grow large.
Why it matters
Financial systems, healthcare, and legal applications often require a complete, immutable audit trail. Event Sourcing makes this a first-class concern rather than an afterthought.
✓ When to use
- →Financial transactions, compliance-heavy domains
- →Debugging requires full history of what happened and when
- →Time-travel queries (what was the state at time T?)
- →Paired with CQRS for complex read projections
✗ When NOT to use
- →Simple domains with no audit requirements
- →When query patterns require current-state access without event replay overhead
- →Teams unfamiliar with eventual consistency
Trade-offs
Complete immutable audit trail by design
Schema evolution of past events is complex
Temporal queries and event replay for debugging
Initial learning curve and operational complexity
In production
Kafka's log is an event-sourced storage system at its core
Git history is a sequence of immutable events (commits)
Ledger entries are never updated — only new entries are appended
Industry adoption
Related principles
CQRS
LiveSeparate the model used to read data (Query) from the model used to write data (Command) — each optimised independently.
Event-Driven Architecture
LiveServices communicate by producing and consuming events asynchronously through a central event bus or message broker.
Domain-Driven Design
Model software around the core business domain using a shared language between developers and domain experts.