What is an event store?
An event store is a database that records ordered, immutable facts about state changes. Instead of keeping only the latest value, it keeps the sequence that produced that value. Applications derive current state through projections and can replay the same history to rebuild or inspect earlier state.
Four parts of the model
Events are facts
Each accepted event records what changed, when it changed, and which stream it belongs to. Corrections append another event; they do not edit history in place.
Streams preserve order
Related events form a stream, commonly scoped to one entity or process. Stream versions support optimistic concurrency and deterministic replay.
Projections answer reads
A projection folds events into a read model: account balance, order status, agent memory, dashboard totals, or any other current-state view.
Replay reconstructs state
Because source events remain available, systems can rebuild a projection, inspect a past point in time, or test corrected logic against recorded history.
Use one when history matters
- Audit and compliance need a traceable sequence of decisions.
- Projections must be rebuilt after logic changes.
- Operators need point-in-time answers or replay debugging.
- Agents must retain provenance across sessions.
Do not use one by default
A current-state database is usually simpler when overwriting rows is acceptable and you do not need replay, provenance, temporal queries, or multiple derived read models. Event sourcing adds modelling, versioning, and projection work; those costs need a real reason.