Introduction

Event Sourcing is a new innovation within the data domain. Where we previously used regular databases, Event Sourcing is an Event-driven-Architecture in which the persistence of data is done through events.

Theory

A bank never records “the new balance of your account is 50E”, they record “$10 transferred from Jan to Kees”, and the balance of your account can be computed as the accumulation of all such events. This practice is referred to Event Sourcing (or also ES). The advertised advantages of this approach are that it implies the existence of an exhaustive audit log(ledger), and it enables performing interesting queries against the entire history of a system without anyone having to decide in advance what metrics were worth logging explicitly.

In Event Sourcing, events are the state. So the flow looks like this:

  • You get the events from the stream (that represents all the facts that happened for the entity),

  • You apply it one by one in the order of appearance to build the current state,

  • You run the business logic and, as a result, create the event,

  • You append a new event.

https://i.imgur.com/WTe53Gv.png

Pro’s

  • Monitoring events using ledgers

  • Real-time data reporting

  • Good for fail-safety

Con’s

  • Complexity to deployment & reliability of streams

  • Requires significant scaffolding

  • Works better with a task-based UI

  • GDPR

An example of a system using ES can be seen below, as an introduction on ES is given by Martin Fowler as seen here: https://martinfowler.com/eaaDev/EventSourcing.html

https://i.imgur.com/n6zqEha.png

And as you can tell, again, that this is a very event-driven development focus of software engineering. Using this example, ships depart & arrive at different ports. By implementing this architecture, you have a log of all the changes. Doing this has various boons:

  • Rebuild the application state by re-running events on an empty application

  • Being able to rerun events up to a specific time or event similar to VCS(Git)

  • Correction of events using the same technique as mentioned above

When to use it (according to Martin Fowler)

Audit trail: With this implementation all of the events that occur are being extensively logged Debugging events: Events can be replayed up to a specific error occuring, granting insights into the nature of the problem.

Parallel models: Recreating past states of code. Retroactive events: Replacing incorrect events that resulted in a bug in the current application state.

Very scalable (horizontal): Systems can operate in a very loosely coupled parallel style

How ES could be applied in Ramses

https://i.imgur.com/tfcXi4e.png

Using this implementation, I could list a few new benefits: if multiple teams were added to this project they could focus on creating more events, and dynamically expand comments with more attributes if required. (For ex: if users of Ramses could rate each others comments.)