Tag Archives: Fulfillment

Fulfillment

web scale patterns in the bol.com back office – Mixed SQL – NoSQL

In the previous weeks, we started a series of blog posts that show you how we use “web scale” patterns to achieve scalability and flexibility in our back office software. The previous patterns discussed were Event Sourcing and CQRS. This week we will dive into mixed SQL – NoSQL. Showing you how this doesn’t just solve a technical problem, they help us solve our business problems!

Mixed SQL – NoSQL

Where needed in our services we are moving away from pure SQL. We create a mix with other types of storage. So we are using NoSQL (Not only SQL). One could also call this polyglot persistence. The notion that your application can write to or query multiple databases or one database with multiple models. It uses the same idea as polyglot programming. This expresses the idea that applications should be written in a mix of languages to take advantage of the fact that different languages are suitable for tackling different problems.

RTN – Billing platform for our retailers

RTN stores all kinds of transactions to charge and pay partners in our LvB (Fulfilment by bol.com) operations. In this part of our operation, we store and fulfil products in our warehouses for retailers that sell their goods on our platform.

The transactions to create invoices for our LvB partners stems from a number of services. We have all kinds of different attributes we want to account for to know why decisions have been made and for auditing purposes. These attributes depend on the transaction type. It was decided that the attributes wouldn’t be a part of the transactions table since they are only filled for a part of the records.

To accommodate for the attributes that depend on the transaction type we created an additional column in the table that is able to store key-value pairs in JSON format. The use of a pure SQL solution would have resulted in a weak design. As would the use of a pure NoSQL. In these cases, they work great together.

FNK – Warehouse orders

FNK processes our customer orders to create warehouse orders. It determines the warehouse that will fulfil the customer demand and instructs the warehouse to fulfil the order. Besides regular warehouses, it also communicates with our warehouse for digital products (e-books and software downloads) and with retailers that sell their products on our platform and take care of the fulfilment themselves.

These retailers have requirements that differ from the other warehouses. To accommodate these while avoiding a to a specific part in this services we introduced an additional column that stores XML. This mixture of SQL (one table for all warehouse orders) and NoSQL (stored XML) results in a simple model that can handle requirements that are only needed for a part of the orders. Since the data in the XML is hardly needed in this service but mostly in downstream services, there are no drawbacks on performance.

What we learned

The NoSQL parts in these mixed data stores are mostly used to read from. If you need to specifically filter on these of have a requirement to use them in joins performance will degrade.

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

In the next week’s episode on the following subject will be published:

  • Micro services
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 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!

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 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:

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 scalability 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 help us solve our business problems!

We need web scale in the back office since more and more functionality from the back office is needed on 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

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 where 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 popularised 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 fulfilment 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 handled by a technically isolated part of the service. Stock levels are served by other services by another isolated part.

Implementation

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 receive 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 week’s episodes on the following subjects will be published:

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.

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.

Een kijkje in het bol.com fulfillment center

Dit filmpje geeft een interessante blik in het huidige bol.com fulfillment center in Waalwijk. Met een drone zijn opnamen gemaakt in een van de hallen van het warehouse.

En een eigen bol.com fulfillment center voor groei en innovatie

Begin 2016 start bol.com met de bouw van een eigen bol.com fulfillment center. Als dat opent heeft het circa 50.000m2 grondoppervlakte. Dat is te vergelijken is met zeven voetbalvelden. Daarmee kan het assortiment worden uitgebreid en kunnen meer leveringsdiensten aan de klanten worden aangeboden.

fulfillment vernieuwingen

Normaal gesproken staat het domein van fulfillment niet volop in de aandacht vanwege de nieuwe ontwikkelingen. In de afgelopen maand heeft bol.com twee fulfillment vernieuwingen aangekondigd, waar ik met mijn collega architecten een bijdrage aan heb geleverd:

Bol.com bouwt eigen fulfillment center voor groei en innovatie

Een eigen fulfilment center biedt meer ruimte om verder te groeien. Daarnaast zorgt het ervoor dat we ons assortiment en onze diensten zoals ‘Vandaag Ophalen’ en ‘Logistiek via bol.com’ kunnen blijven uitbreiden. Ook biedt het de mogelijkheid om verder te kunnen innoveren met een nog snellere en betrouwbaardere levering. Gemak voor klanten staat daarbij voorop.

fulfillment centerHet nieuwe fulfillment center, dat in 2017 zijn deuren zal openen zal bij de opening circa 50.000m2 grondoppervlakte hebben. Dat is te vergelijken is met zeven voetbalvelden. De komst van het nieuwe bol.com fulfilment center betekent voor Waalwijk en omgeving opnieuw een groei in het aantal arbeidsplaatsen.

Bol.com kiest voor eigen DC en handmatig pickproces

Naar aanleiding van het bovenstaande nieuws gaf de logistiek directeur van bol.com Huub Vermeulen een interview aan het blad Logistiek. Dit achtergrond artikel geeft een interessant inkijkje in e-fulfillment bij bol.com.

Korting bij aankoop van de grond in Waalwijk

Volgens het Brabants Dagblad heeft Bol.com heeft een fikse korting gekregen op grond die het in Waalwijk heeft gekocht voor de bouw van een nieuw distributiecentrum. Uit de hypotheekakte blijkt dat de webshop voor 10,6 miljoen euro tien hectare grond heeft gekocht aan de Kloosterheulweg nummer 14. Omgerekend betaalt de dochter van Ahold 106 euro per vierkante meter, exclusief btw. Dat is fors minder dan de prijs die de gemeente Waalwijk doorgaans voor haar grond vraagt; 140 euro per vierkante meter.

Vandaag ophalen – Same day delivery betaalbaar

bol.com afhaalpuntDe andere fulfillment vernieuwing waar klanten direct van profiteren is Vandaag Ophalen. Vandaag ophalen is een nieuwe dienst die vandaag leveren betaalbaar en makkelijk maakt. Klanten kunnen al binnen enkele uren na bestelling hun pakketje ophalen bij Albert Heijn. Bestellingen die op werkdagen ’s morgens vóór 12.00 uur zijn gedaan, liggen nog dezelfde dag ’s middags klaar bij het afhaalpunt, uiterlijk om 17.00 uur.

Michel Schaeffer, marketingdirecteur bij bol.com:

Binnen e-commerce maken nog maar weinig consumenten gebruik van ‘same day delivery’, omdat ze meestal niet bereid zijn hoge bezorgkosten te betalen. Bij de ontwikkeling van Vandaag Ophalen hebben wij dan ook lage kosten voorop gezet. Door de bezorging van bestellingen te combineren met een dagelijkse bezigheid – boodschappen doen – hebben we de dienst niet alleen betaalbaar maar ook makkelijk gemaakt. Zo kunnen consumenten op één moment van de dag in één winkel terecht voor al hun aankopen. Hiermee maken we ‘same day delivery’ toegankelijk en bewijzen we opnieuw dat online winkelen oneindig veel mogelijkheden heeft.