What is the Event Sourcing pattern?
Instead of overwriting a row, append an event such as OrderPlaced or ItemAdded to an event store. The current state of an entity is the result of applying its events in order, with periodic snapshots to keep replay fast. Other components build projections from the same events.
What problem does the Event Sourcing pattern solve?
You get a complete audit trail, the ability to rebuild any view from history, and a natural stream of integration events. It suits domains where how you got to a state matters as much as the state itself.
How do you implement the Event Sourcing pattern?
- Model aggregates and the business events they emit, named in the past tense.
- Append events with optimistic concurrency so two writers cannot overwrite each other.
- Rebuild state by replaying, and snapshot after N events to keep it fast.
- Publish events to build projections and notify other services.
- Plan for event schema changes with versioning or upcasting from day one.
When should you use it?
- Audit, compliance or temporal queries are first-class requirements.
- The domain is behaviour-rich, such as ledgers, bookings or logistics.
When should you avoid it?
- Simple CRUD data with no history needs.
- The team has no experience with it and no time to learn. The learning curve is steep.
- Personal data must be erasable, unless you design for it, for example with encryption keys you can delete.
What do you gain?
- Full history and audit
- Rebuild views at any time
- Natural source of integration events
What does it cost?
- Steep learning curve
- Event schema evolution is hard
- Querying needs projections
- Deleting data is awkward
What are common mistakes with the Event Sourcing pattern?
- CRUD-style events like RowUpdated that carry no business meaning.
- Editing past events instead of appending corrections.
- Publishing internal events directly as the public API.
Event Sourcing in practice
Brightledger Payments
Account balances were updated in place. During reconciliation the team could not explain how some balances had been reached, because the history was gone.
The ledger now stores every money movement as an immutable event, and balances are computed from those events. Auditors can replay any account to any point in time, and read views are maintained as projections.
Example decision record
- Context
- Financial records must be fully auditable and reproducible at any point in time.
- Decision
- Use event sourcing as the persistence model for the ledger domain.
- Consequences
- Every change is recorded as an immutable event.
- Read views are maintained by projections, with CQRS for queries.