Event Sourcing
Event Sourcing
Capture all changes to an application state as a sequence of<br>events.
Martin Fowler
12 December 2005
This is part of the Further Enterprise Application Architecture development writing that I was doing in the mid 2000’s. Sadly too many other things have claimed my attention since, so I haven’t had time to work on them further, nor do I see much time in the foreseeable future. As such this material is very much in draft form and I won’t be doing any corrections or updates until I’m able to find time to work on it again.
We can query an application's state to find out the current<br>state of the world, and this answers many questions. However there<br>are times when we don't just want to see where we are, we also<br>want to know how we got there.
Event Sourcing ensures that all changes to application state are<br>stored as a sequence of events. Not just can we query these<br>events, we can also use the event log to reconstruct past states,<br>and as a foundation to automatically adjust the state to cope with<br>retroactive changes.
How it Works
The fundamental idea of Event Sourcing is that of ensuring every<br>change to the state of an application is captured in an event<br>object, and that these event objects are themselves stored in the<br>sequence they were applied for the same lifetime as the<br>application state itself.
Let's consider a simple example to do with shipping<br>notifications. In this example we have many ships on the high<br>seas, and we need to know where they are. A simple way to do this<br>is to have a tracking application with methods to allow us to tell<br>when a ship arrives or leaves at a port.
Figure 1: A simple interface<br>for tracking shipping movements.
In this case when the service is called, it finds the relevant<br>ship and updates its location. The ship objects record the current<br>known state of the ships.
Introducing Event Sourcing adds a step to this process. Now the<br>service creates an event object to record the change and processes<br>it to update the ship.
Figure 2: Using an event to<br>capture the change.
Looking at just the processing, this is just an unnecessary<br>level of indirection. The interesting difference is when we look<br>at what persists in the application after a few changes. Let's<br>imagine some simple changes:
The Ship 'King Roy' departs San Francisco
The Ship 'Prince Trevor' arrives at Los Angeles
The Ship 'King Roy' arrives in Hong Kong
With the basic service, we see just the final state captured by<br>the ship objects. I'll refer to this as the application state.
Figure 3: State after a few<br>movements tracked by simple tracker.
With Event Sourcing we also capture each event. If we are using a<br>persistent store the events will be persisted just the same as the<br>ship objects are. I find it useful to say that we are persisting<br>two different things an application state<br>and an event log.
Figure 4: State after a few<br>movements tracked by event sourced tracker.
The most obvious thing we've gained by using Event Sourcing is that we<br>now have a log of all the changes. Not just can we see where each<br>ship is, we can see where it's been. However this is a small<br>gain. We could also do this by keeping a history of past ports in<br>the ship object, or by writing to a log file whenever a ship<br>moves. Both of these can give us an adequate history.
The key to Event Sourcing is that we guarantee that all changes to the<br>domain objects are initiated by the event objects. This leads to a<br>number of facilities that can be built on top of the event log:
Complete Rebuild: We can discard the application state<br>completely and rebuild it by re-running the events from the event log<br>on an empty application.
Temporal Query: We can determine the application state at<br>any point in time. Notionally we do this by starting with a blank<br>state and rerunning the events up to a particular time or event. We<br>can take this further by considering multiple time-lines (analogous to<br>branching in a version control system).
Event Replay: If we find a past event was incorrect, we can<br>compute the consequences by reversing it and later events and then<br>replaying the new event and later events. (Or indeed by throwing away<br>the application state and replaying all events with the correct event<br>in sequence.) The same technique can handle events received in the<br>wrong sequence - a common problem with systems that communicate with<br>asynchronous messaging.
A common example of an application that uses Event Sourcing is a<br>version control system. Such a system uses temporal queries quite<br>often. Subversion uses complete rebuilds whenever you use dump and<br>restore to move stuff between repository files. I'm not aware of<br>any that do event replay since they are not particularly<br>interested in that information. Enterprise applications that use<br>Event Sourcing are rarer, but I have seen a few applications (or parts of<br>applications) that use it.
Application State Storage
The simplest way to think of using Event Sourcing is to calculate...