Event Sourcing
Pattern where application state is derived from an immutable sequence of events, providing complete audit trail and the ability to reconstruct state at any point in time.
seed#event-sourcing#events#audit#immutable#patterns#architecture
What it is
Event sourcing stores state as a sequence of immutable events instead of just the current state. To know the current state, all events are replayed from the beginning. Each event represents something that happened and cannot be modified.
Traditional state vs Event Sourcing
| Traditional | Event Sourcing |
|---|---|
| Stores current state | Stores events |
| UPDATE overwrites | Append-only |
| No history | Complete history |
| One model | Multiple projections |
Example
Event 1: AccountCreated { id: 123, holder: "Ana" }
Event 2: DepositMade { id: 123, amount: 1000 }
Event 3: WithdrawalMade { id: 123, amount: 200 }
Current state: { id: 123, holder: "Ana", balance: 800 }
Benefits
- Complete and immutable audit trail
- Reconstruct state at any point in time
- Multiple projections from the same events
- Debugging: replay exactly what happened
Challenges
- Event schema evolution
- Performance with many events (snapshots)
- Conceptual complexity
Why it matters
Event sourcing stores every state change as an immutable event, providing a complete audit trail and the ability to reconstruct state at any point in time. It is especially valuable in financial, legal, and compliance domains where traceability is mandatory.
References
- Event Sourcing — Martin Fowler.
- Event Store — Event Store, 2024. Database designed for event sourcing.
- Event Sourcing Pattern — Azure — Microsoft, 2024. Pattern implementation guide.