All actions are stored as events.
All states of all entities can be restored at any time, e. g. the bank account of a user.
Instead of storing the value of the bank account in the database, a log of events is stored. For computing the current value, all events are considered and replayed. This step is called "hydrating". When having a lot of events, this becomes a huge workload.
- Hydration
- Replay
The related database for an event sourcing product is often called an event store.
Typical scenarios for event-sourcing based data storage:
- Situations, in which transparency is necessary (finances), where it must be clear how the current state was derived. Just think about a bank account.
- When rolling back to previous states is needed
- What-if use cases, e. g. in data science
- AI / ML applications, when training data for predicting events is necessary
- Event-driven architectures