Event store

From Wikipedia, the free encyclopedia

An event store is a type of database optimized for storage of events.

Conceptually, in an event store, only the events of a dossier or policy are stored. The idea behind it is that the dossier or policy can be derived from these events. The events (and their corresponding data) are the only "real" facts that should be stored in the database. The instantiation of all other objects can be derived from these events. The code instantiates these objects in memory. In an event store database, this means that all objects that should be instantiated, are not stored in the database. Instead these objects are instantiated 'on the fly' in memory by the code based on the events. After usage of these objects (e.g. shown in a user interface), the instantiated objects are removed from memory.

Example with insurance policies[edit]

For example, the event store concept of a database can be applied to insurance policies or pension dossiers. In these policies or dossiers the instantiation of each object that make up the dossier or policy (the person, partner(s), employments, etc.) can be derived and can be instantiated in memory based on the real world events.

Double timeline[edit]

A crucial part of an event store database is that each event has a double timeline: This enables event stores to correct errors of events that have been entered into the event store database before.

The two dates are:

  • Valid date is the date at which the event has become valid.
  • Transaction date is the date at which the event is entered into the database.

Error correction[edit]

Another crucial part of an event store database is that events that are stored are not allowed to be changed. Once stored, also erroneous events are not changed anymore. The only way to change (or better: correct) these events is to instantiate a new event with the new values and using the double timeline. A correcting event would have the new values of the original event, with an event data of that corrected event, but a different transaction date. This mechanism ensures reproducibility at each moment in the time, even in the time period before the correction has taken place. It also allows to reproduce situations based on erroneous events (if required).

Advantages and disadvantages[edit]

One advantage of the event store concept is that handling the effects of back dated events (events that take effect before previous events and that may even invalidate them) is much easier.

An event store will simplify the code in that rolling back erroneous situations and rolling up the new, correct situations is not needed anymore.

Disadvantage may be that the code needs to re-instantiate all objects in memory based on the events each time a service call is received for a specific dossier of policy.

Compared to regular databases[edit]

In regular databases, handling backdated events to correct previous, erroneous events can be painful as it often results in rolling back all previous, erroneous transactions and objects and rolling up the new, correct transactions and objects. In an event store, only the new event (and its corresponding facts) are stored. The code will then redetermine the transactions and objects based on the new facts in memory.

See also[edit]

  • Temporal database, a database which stores data relating to time instances (e.g. past, present and future) to determine transactions, validity or decisions

External links[edit]