Docs Event Sourcing PoC

Event Sourcing PoC

You can find the repositories on GitLab.

Introduction

The objective of this PoC is to showcase the feasibility of using an event sourcing pattern, for the purpose of how governmental institutes deal with datasets.

Motivation

Currently most governmental institutes maintain their own datasets. These datasets usually contain recent states only. This approach introduces challenges if these institutes need to cooperate with one another, as it is quite common that the datasets involved contain conflicting data. Additionally, it is (near to) impossible to determine what the state was at a certain point in time, since generally speaking, only recent states are saved.

Event sourcing

The current approach of dealing with data, has proven to be severly limiting. A more flexible & efficient approach, would be to utilise an event sourcing pattern. In a nutshell, it boils down to the recording (into so called event-stores) of each state change, in the form of an event. In turn, applications (read models) can playback these events, to generate customised views of applicable states. As a bonus, events can be replayed to a certain point in time, providing the ability to retrieve historical states.

Backend

This component acts as an append-only event-store. Events are submitted by the client, which in turn are consumed by the read-model.

Read model

The read model consumes events that are stored in the event store, to build views, based on a customisable model, which reflect a particular state. These views are used by the client, to represent a state to the end-user.

Client

The client gives the end-user the possibility to store events and to retrieve particular states that have been generated by the read-model.

Diagram

diagram

Resources