Event Sourcing became another buzzword these days, so we decided to write an introductory article to explain the main concept behind it and list down all the event sourcing benefits that you might get implementing it.

The main idea behind Event Sourcing

Basically, Event Sourcing ensures that all changes to application state are stored as a sequence of events. Not just can we query these events, we can also use the event log to reconstruct past states, and as a foundation to automatically adjust the state to cope with retroactive changes.

Let’s consider a simple example: shipping notifications. Introducing Event Sourcing creates an event object to record the change and processes it to update the ship. Not just can we see where each ship is, we can see where it’s been.

Also, a common example of an application that uses Event Sourcing is a version control system. Such a system uses temporal queries quite often. Subversion uses complete rebuilds whenever you use dump and restore to move stuff between repository files.

There are a number of choices about where to put the logic for handling events. The primary choice is whether to put the logic in Transaction Scripts or Domain Model. Usually, Transaction Scripts are better for simple logic and a Domain Model is better when things get more complicated.

Martin Fowler believes that the key to Event Sourcing is that it guarantees that all changes to the domain objects are initiated by the event objects. This leads to a number of facilities that can be built on top of the event log:

1. Complete Rebuild: we can discard the application state completely and rebuild it by re-running the events from the event log on an empty application.
2. Temporal Query: we can determine the application state at any point in time. Notionally we do this by starting with a blank state and rerunning the events up to a particular time or event.
3. Event Replay: if we find a past event was incorrect, we can compute the consequences by reversing it and later events and then replaying the new event and later events.

Some other Event Sourcing benefits

• • Scalability
    Event Sourcing also raises some possibilities for your overall architecture, particularly if you are looking for something that is very scalable. There is a fair amount of interest in event-driven architecture these days. This term covers a fair range of ideas, but most of centers around systems communicating through event messages. Such systems can operate in a very loosely coupled parallel style which provides excellent horizontal scalability and resilience to systems failure.

• • 100% accurate audit logging
    Auditing functionality is often added as an afterthought, resulting in an inherent risk of incompleteness. With event sourcing, each state change corresponds to one or more events, providing 100% accurate audit logging.

• • Expressive models
    Event Sourcing forces you to model events as first class objects, rather than through implicit state changes. This means your models will closely resemble the actual processes you’re modelling. This brings a lot of clarity to the table and stops you getting lost in the details of your storage technology. It makes the implicit explicit.

• • Reports become painless
    You have the full history of every event that has ever happened, in chronological order, this means you can ask any question you like about that data historically.

• • Easy to change database implementations
    Due to the ephemeral nature of event sourced data-structures, you now have full freedom to use any database technology you like to store state.

I hope it gives you a good overview of what is event sourcing and why companies implement it. If you have any questions, feel free to ask them in the comments section below or sending us a message, we would be happy to help!