Event store
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.
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.
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.
- 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.
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).
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. 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 it's corresponding facts) are stored. The code will then redetermine the transactions and objects based on the new facts in memory.
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.
External links
- DB-Engines Ranking of Event Stores by popularity, updated monthly