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)
  • What-if use cases, e. g. in data science
  • Event-driven architectures