Event sourcing
Storing every change as an event in an append-only log and rebuilding current state by replaying it, instead of storing only the latest state.
An account is not a row with a balance but a list: opened, deposited, withdrawn. You get a full audit trail and can build new reports by replaying history. The costs stay for the life of the system: old events must keep working when their shape changes, long histories need snapshots, and every query needs a projection. Adding it next to an existing database usually means two sources of truth that disagree (split-brain).
Related terms
- CQRS (Command Query Responsibility Segregation): Splitting a system into a write side that changes data and a separate read side shaped for queries, kept in sync by events.
- Split-brain: Two parts of a system both believe they hold the truth and accept changes independently, so their data drifts apart.
- WAL (write-ahead log): A database’s log of every change, written before the data files, which makes crash recovery, replication and point-in-time restore possible.
