Last week we started a series of blog posts we show you how we use “web scale” patterns to achieve scalability and flexibility in our back office software. Last week’s pattern we discussed was CQRS. This week we will dive into Event Sourcing. Showing you how this doesn’t just solve a technical problem, they help us solve our business problems!
The idea of Event Sourcing is that every change to the state of a system is captured in sequence and that these events can be used to determine the current state. Consequently, the state of the system for any point in time can be determined by replaying the events. The structure of the service changes from storing state to storing events.
The most obvious that we gain by using Event Sourcing is that we have a log of all the changes. We can see everything that happened. This enables us to:
- Do a complete rebuild;
- Determine the state of the system at any point in time;
- Event replay – Compute the consequences of a change in a past event of recalculate the consecutive states based on the proper sequence of events (in case messages in an asynchronous communication weren’t received in the proper order).
Using Event Sourcing can feel a little bit awkward for some developers. However, it offers a variety of opportunities. One could replay the events on a test environment to see exactly what happened on pro, while you have the ability to stop, rewind and replay the events running a debugger. This provides also a way to do parallel testing before promoting an upgrade to production.
Where do we use it at bol.com?
One of the examples where we use Event Sourcing is Condition Management and especially the calculations of accruals and invoices for (purchasing) conditions. A large set of our purchasing conditions is based on either purchasing amounts or values and sales amounts and values. In general these purchasing conditions have to attributed to (sets of) single products, product categories, suppliers and brands.
Storing the events that represent the purchase and sales of goods allows us to implement functionality that would be very hard to develop if we wouldn’t. Typically a purchasing condition isn’t agreed with a supplier of a brand on the first of January. While it could be valid from the first of January. The Event Sourcing model allows us to handle conditions that are entered into the system somewhere in March or April that are valid from the first of January. These conditions will be handled by passing all the events from the start date and the appropriate accruals and invoice can be created.
With the Event Sourcing model, we are also more loosely coupled to the source services for purchasing and sales. Our calculations can handle events that are captured out of sequence or even very late. Condition values are still calculated properly and handled as accounting and controlling have prescribed.
For the future, we are planning to implement scenario run through and comparisons. This would support our buyers while negotiating with suppliers.
Next in web scale patterns in the bol.com back office
In the next week’s episodes on the following subjects will be published:
- Polyglot persistence
- Micro services