In my last post I looked at what events are, why they might be helpful to you, where they come from and some possible ways of dealing with them. At the end of the post I briefly mentioned that Event Sourcing may be helpful to you, in some capacity.

But what is Event Sourcing?

In an event driven system once an event has been processed it disappears. During the processing of the event the state of the system will change, and these changes will be updated into system storage. Without implementing complex auditing going back to a previous system state isn’t possible.

In an event sourced architecture the system is setup to store all of the events (including metadata) that pass through the system in an append only store. This means that it is possible to understand how the system arrived a it’s current state, or even to replay the events to recreate the state. The important point to come away with is that the event store is the single source of truth with regards to system state.

Microsoft have a really good overview of event sourcing in their series of articles on Cloud Design Patterns: Event Sourcing pattern.

So how do I do Event Sourcing?

Essentially you have two routes to consider. The first route is to Do It Yourself (DIY). You add something to your event driven system that causes all events that pass through the system to be stored in some long term storage. With RabbitMq this can be as easy as adding a queue to each exchange that takes all messages and persists them. You will also need to persist all of the metadata, like routing keys, as this may be important in the event that the events are replayed. You’ll also need to consider how you are going to deal with event replays, and there are two aspects to consider here:

  1. How do events get replayed into the system?
  2. How do you deal with events that have been replayed (especially when they hit your storage mechanism)?

The other alternative is to use a pre-existing event-sourcing tool in your system. These are a little thin on the ground, but luckily there is one available, Event Store (sometimes also called Get Event Store or GES).

Getting started with Event Store

There are many routes to getting Event Store on to your machine, but I’m going to go down the docker route as it’s a lot tidier. (N.B. be sure to take note that this image is only for development purposes.)

Once you’ve got Event Store running locally you can access it on http://localhost:2113 admin:changeit.

When I was getting started with Event Store I found Rob Ashton’s Blog Series really useful:

These five posts gave me a lot of information and pointers on the power of event sourcing in general and Event Store in particular. The next eight posts form an interesting project:

There’s already an awful lot of information here to consider, so in future posts we’ll look at how to tie chains of events together, what happens when you change a query, and other things.