Event Sourcing stores the state of an application as a sequence of events rather than just the current state.
Core Concept
Instead of storing:
User { id: 1, name: "Alice", email: "alice@example.com" }
Store the events:
UserCreated { id: 1, name: "Alice", email: "alice@example.com" }
EmailChanged { id: 1, newEmail: "alice@newdomain.com" }
Current state is derived by replaying events.
Benefits
Complete Audit Trail
- Every state change is recorded
- Natural audit log for compliance
- Can answer “what was the state at time X?”
Time Travel
- Reconstruct past states
- Debug production issues by replaying events
- Test against historical scenarios
Event-Driven Architecture
- Events can trigger other services
- Natural fit for message queues and pub/sub
- Enables reactive systems
Flexibility
- Add new projections without changing event store
- Support multiple read models from same event stream
Challenges
Complexity
- More complex than CRUD
- Need to handle event schema evolution
- Eventual consistency between event store and projections
Storage Growth
- Events accumulate over time
- Snapshots needed for performance
- Archival strategy required
Learning Curve
- Different mental model from traditional CRUD
- Requires understanding of CQRS patterns
Common Patterns
CQRS (Command Query Responsibility Segregation)
- Separate write model (commands → events) from read model (projections)
- Often used together with event sourcing
Snapshots
- Periodically save current state to avoid replaying all events
- Trade-off between storage and replay performance
Use Cases
- Financial systems (transaction history)
- Collaborative editing (change tracking)
- Workflow systems (state transitions)
- Analytics (rich historical data)
References
See also: Message Queues