Event Sourcing
Every application has a state, representing current snapshot at the moment. Event sourcing is the idea of persisting all of these states as it changes from one to another.
Imagine a workflow for an invoice goes something like: invoice is created which set the status to pending. Pending invoice then gets approved which sets it approved. Approved invoice can be denied or collected. When invoice is denied, it goes back to pending, but when it’s collected, it becomes closed. The state of an invoice is where it’s at a particular time. However, when event sourcing pattern is implemented, we will be able to see a historical timeline of an invoice, from when it’s created to the current state.
What this allows us to do is, we are able to:
- Complete rebuild: getting rid of the current state and use events to rebuild the invoice to its current state.
- Temporal query: we can tell what state an invoice is at particular point in time.
- Event replay: when the past event is incorrect, we can make the change and compute it from the beginning, thus, replaying the whole series of events.
Some applications of event sourcing are:
- Source control. Every source control uses time series where commits made change the code. By storing events for every commit, we are able to state of the code at particular point in time.
- Redo / undo. Applications that utilize undo / redo, such as word processor, will benefit from event sourcing pattern.
- Document history. Word processor application will also benefit from event sourcing by storing event every time changes are made.
I hope this simple explanation of event sourcing helps you to understand what it is and how we can use it. There’s definitely a lot more to it that I don’t cover here, but there are lots of resources online you can learn from.