web scale patterns in the bol.com back office

web scale patterns in the bol.com back office – Event Sourcing

Last week we started a series of blog posts we show you how we use “web scale” patterns to achieve scaleability and flexibility in our back office software. Last weeks pattern we discussed was CQRS. This week we will dive in to Event Sourcing. Showing you how this doesn’t just solve a technical problem, they helps us solve our business problems!

Event Sourcing

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?

web scale patterns in the bol.com back officeOne 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 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 weeks episodes on the following subjects will be published:

  • Polyglot persistence
  • Micro services
web scale patterns in the bol.com back office – CQRS

web scale patterns in the bol.com back office – CQRS

In this series of blog posts we show you how we use “web scale” patterns to achieve scaleability and flexibility in our back office software. We will guide you through how we apply patterns like CQRS, event sourcing and micro services to solve puzzles in our back office services. These patterns don’t just solve a technical problem, they helps us solve our business problems!

We need web scale in the back office since more and more functionality from the back office is needed in the web site to offer better service to our customers. For example more parts of our web shop do request on our stock levels and warehouse configuration to determine how fast product can be delivered to our customers and with what options. Consequently the services that know our stocks levels and warehouse configuration also have to be scaled to handle these volumes. To enable this we don’t just need more hardware, we also need to apply patterns to our services to create a proper structure.


CQRS is short for Command Query Responsibility Segregation. At the core of CQRS is the notion that a different model can be used to alter data than the model that is used to query data. Updating and reading information have different requirements on a model. There are enough cases were it serves to split these. The downside of this separation is that it introduces complexity. So this pattern should be applied with caution.

The most common approach for people to interact with data in a service or system is CRUD. Create, Read, Update and Delete are the four basic operations on persistent storage. The term was likely popularized by James Martin in his 1983 book Managing the Database environment. Although there exist other variations like BREAD and MADS, CRUD is widely used in systems development.

When a need arises for multiple representations of information and users interact with these multiple representations, we need something that extends CRUD. This because the model to access the data tends to be split over several layers and becomes overly complicated.

What CQRS adds

CQRS introduces a split into separate models for update and display, Command and Query respectively. The rationale for this is that for many problems in more complex domains having the same model for commands and queries leads to a more complex model. A model that does neither well.

Where do we use it at bol.com?

One of the examples of where we use CQRS in the back office services at bol.com is in our Inventory Management. Inventory Management handles all updates on stock levels and serves them to several services in out landscape including our web shop.

The updates of stock levels come from our warehouse management and include reservations based on customer orders, shipments and received goods. The queries on the stock level originate in the web shop, check out and fulfillment network. As you can imagine these queries have quite a different profile compared to the updates. Besides that the number of queries far outreaches the number of updates.

Given these different requirements we decided to split command (updates) and query for inventory management. All updates are handles by a technical isolated part of the service. Stock levels are served to other services by another isolated part.


web scale patterns in the bol.com back office – CQRSThe part that handles the updates has several models. The incoming changes like the shipments and received goods have to be handled in for example stock mutations, stock levels and stock valuation. These models receives updates and process them to a new stock level and stock valuation. Once a new stock level is calculated, it is published on a messaging queue to the query part. This message is also consumed by other services that need these.

The query part is a simple single table. The messages from the update part are stored in this table and there is no additional logic or processing. Queries from other services are handled by a REST interface. Due to this design this call has a very high cache hit ratio. Which of course leverages performance.

Next in web scale patterns in the bol.com back office

In the next weeks episodes on the following subjects will be published:

  • Event Sourcing
  • Polyglot persistence
  • Micro services

Presentatie Agile schalen op basis van best practices

Net als de afgelopen jaren heb ik afgelopen vrijdag een presentatie over Agile Architectuur gegeven. Kern van de presentatie dit jaar is dat bij het schalen van Agile vooral de problemen/uitdagingen die je onderweg tegenkomt aangepakt moeten worden en niet klakkeloos een framework gaat implementeren. Aan de hand van voorbeelden leg ik uit hoe we dit binnen bol.com aanpakken.

Book – Holacracy

HolacracyIk kwam een mooie samenvatting van het boek Holacracy van Brian J. Robertson tegen. Eerder schreef ik een review over Getting Teams Done. Waarin holacracy (en de variant Spark) beschreven wordt als een methode voor teamproductiviteit, net als GTD dat is voor individuele productiviteit. Mijn ervaringen met de holacracy variant Spark beschreef ik in deze post.

De case die vaak gegeven wordt als holacracy adoptie beschreven wordt is Zappos, maar er zijn veel meer cases beschreven.

Presentatie op LAC congres – Agile schalen op basis van best practices

lac-agile-schalen-op-basis-van-best-practicesOp donderdag 17 en vrijdag 18 november is de 18e editie Landelijk Architectuur Congres. Net als vorig jaar ga ik in de track Agile Architecting een presentatie geven over architectuur en architecten in een Agile omgeving. De titel van de presentatie dit jaar is: Agile schalen op basis van best practices.

Bij bol.com hebben we jarenlange ervaring met het werken met agile en scrum. Het aantal IT teams dat hiermee werkt is de laatste 2 jaar enorm sterk gegroeid. Daarnaast doen we diverse experimenten met holacracy. Voor het opschalen zijn we steeds op zoek gegaan naar best practices. Je zal dan ook veel elementen uit SAFe terug zien, maar nooit SAFe.

Agile schalen op basis van best practicesIn de meer dan 100 scrum sprints die we er bij bol.com inmiddels op hebben zitten hebben we een berg ervaring opgedaan met agile architectuur en het schalen van agile practices. Architectuur kan een belangrijke bijdrage leveren aan een snellere time-to-maket. In de presentatie zullen voorbeelden gebruikt worden uit bijvoorbeeld de realisatie van sneller en vaker leveren, de winkel langer open en Logistiek via bol.com.

Sneller en vaker leveren

Onze winkel gaat sneller en vaker leveren. Zoals je in de afbeelding kan zien is het maar een kleine aanpassing in de front-end/website. Zoals met veel fulfillment aanpassingen zit er een hele wereld van planning en operatie achter om dit ook daadwerkelijk voor elkaar te krijgen.
Sneller en vaker leveren

Sneller en vaker leveren maakt het met de al bestaande leveropties voor klanten mogelijk om de levering van bestellingen af te stemmen op hun behoefte.

Organizational Debt

Organizational DebtEveryone knows what debt is. If you are in or around the software development community you probably also know the term technical dept. For others:

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.

Or as Ward Cunningham describes it:

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite … The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation.”

But there is a third kind of debt: Organizational Debt. Here we pay interest on bad decisions of decisions that we put off. This of course has a strong impact on organizations.

Some definitions of Organizational Debt

In organizational debt is like technical debt but worse Steve Blank gives this definition:

Organizational debt is all the people/culture compromises made to “just get it done” in the early stages of a startup.

However I think that organizational debt isn’t a startup thing. It is worse in other organisations since there is a large accumulation of bad decisions and decisions not taken. Besides that larger and/or older organizations tend to have more rules to work around.

That is why I like the shorter description offered by Scoot Belsky in Avoiding Organizational Debt:

Organizational debt is the accumulation of changes that leaders should have made but didn’t.

Another interesting description is given by Aaron Dignan in How to eliminate organizational debt

The interest companies pay when their structure and policies stay fixed and/or accumulate as the world changes.

This one really goes from the VUCA point. The ever changing world in which organizations have to adapt or are to be extinct.

De winkel langer open

Vanaf eind augustus is de winkel langer open. Zoals je in de afbeelding kan zien is het maar een kleine aanpassing in de front-end/website. Zoals met veel fulfillment aanpassingen zit er een hele wereld van planning en operatie achter om dit ook daadwerkelijk voor elkaar te krijgen.
Bol.com de winkel langer open 2359
Je kunt je voorstellen er samen met warehousing en transport partners en de logistieke operatie van alles geregeld moest worden om deze nieuwe belofte waar te maken. Want de winkel langer open, betekent ook dat mensen langer moeten werken etc.
Daarnaast waren er ook diverse aanpassingen nodig in diverse IT systemen. Denk hierbij aan de bepaling bij welke producten deze belofte wel of niet waar gemaakt kan worden.

Global Innovation Index 2016

The Global Innovation Index (GII) 2016 is an annual publication which features a composite indicator that ranks countries/economies in terms of their enabling environment to innovation and their innovation outputs. The GII covers 141 economies around the world and uses 79 indicators across a range of themes. The Global Innovation Index 2016 was created by Cornell University, INSEAD, and the World Intellectual Property Organization (WIPO). The theme of the 2016 Global Innovation Index (GII) is ‘Winning with Global Innovation’.

Here is an overview of the indicators that are used to create the innovation index and how they are related:
Global Innovation Index factors

And this is how the measures are calculated:

  • The Global Innovation Index is the simple average of the Input and Output Sub-Indices.
  • The Innovation Efficiency Ratio is the ratio of the Output Sub-Index over the Input Sub-Index.
  • The Innovation Input Sub-Index is the simple average of the first five pillar scores.
  • The Innovation Output Sub-Index is the simple average of the last two pillar scores.

Global Innovation Index Ranking

Here is the 2016 ranking for the Global Innovation Index. Switzerland, Sweden, the United Kingdom (UK), the United States of America (USA) and Finland are the world’s five most-innovative nations:

  1. Switzerland
  2. Sweden
  3. United Kingdom
  4. United States of America
  5. Finland
  6. Singapore
  7. Ireland
  8. Denmark
  9. Netherlands
  10. Germany

The Netherlands falls five ranks to 9th place, mostly driven by an FDI-related (Foreign Direct Investment) variable and missing data points.

The GII rankings have shown a remarkable level of global diversity among innovation leaders over the years. Among the top-ranked 25 innovative nations this year are not only economies from Northern America (such as Canada and the USA) and Europe (such as Germany, Switzerland, the UK and the Netherlands) but also from South East Asia, East Asia, and Oceania (such as Australia, Japan, Korea, and Singapore) and Northern Africa and Western Asia (Israel).

The distance between the performance of the top 10 ranked innovation nations and all others is still wide. The innovation divides remains in 2016 according to the GII 2016.

The Netherlands in the Global Innovation Index

The Netherlands has been ranked in the top 10 economies of the GII since 2008. It’s faal on the ranking this year is largely because of methodological considerations (see below). This year its ranking is affected by its lower ranks on both the Innovation Input Sub-Index (12th) and the Innovation Output Sub-Index (9th).

The Netherlands achieves a top 25 ranking among all economies for all pillars of the GII, with a better ranking this year in Infrastructure (12th) and Business sophistication (9th). Conversely, the Netherlands’ performance falls at the pillar level in Knowledge and technology outputs, where it ranks 16th overall. This change is mainly a consequence of lower rankings in the Knowledge diffusion sub-pillar (114th) and the indicator FDI net outflows (118th).

The latter indicator, identified as highly volatile in previous GII editions, partly drives the fall in the ranking of the Netherlands. Also, for some new variables—namely, IP receipts and ICT services exports — the Netherlands lacks data.

Scrum guide is updated

Scrum Guide Scrum Values Just last week the latest update of the Scrum Guide was released. In this latest version of the Scrum Guide the five values of scrum play a more important role than in previous versions. In my 4 year old Scrum Guide Mind Map these values aren’t around.

These values amplify the power of Scrum by providing a compass for decision making. They help teams adopt Scrum and deliver amazing software for their customers. They also prove fundamental to create a great place to work.

Scrum values

The Scrum values are:

  • Courage – Being transparent, but willing to change even if that means accepting that you are wrong, or that your opinion is not the direction that the team is going.
  • Focus – focus on what’s most important now without being bothered by considerations of what at some point in time might stand a chance to become important.
  • Commitment – commitment is about dedication and applies to the actions, the effort, not the final result.
  • Openness – Highlighting when you have challenges and problems that are stopping you from success. The empiricism of Scrum requires transparency, openness. We want to inspect reality in order to make sensible adaptations.
  • Respect – Helping people to learn the things that you are good at and not judging the things that others aren’t good at.

There is an interesting post on these values by Gunther Verheyen.