Last wednesday i was offered, in a mail i received, the opportunity to start shopping on friday at 1500hours CET for an very specific item, Instant film at an incredible price. So come last friday, I was ready and braced to start shopping. Unfortunately and to be expected, i was not alone. I was able to get 3 packs of film in my shopping basket, enter my details, select a payment method, and ... just when all I needed to do was confirm the whole thing the site hung up on me and when the site reacted again all stock was gone. This felt very wrong: I was almost there, I had the items in my shopping cart, i was in the checkout line, i should have been able to buy it. It got me thinking how to handle such a thing. So out of this negative experience, i mailed to the support of the site, claiming the way they handled the shopping cart was wrong (maybe i should have said: could be improved), because i was expecting that if i could place items in the shopping basket, i would also be able to buy them; and also to be able to let them know i was unhappy, and hoping they could do something about it come next time. They did reply, though:

Sorry, but that's the way our shop works: until you click the "place order" button, the stock is not reserved for you. Only by confirming your order, you are then guaranteed the order. Stock is subtracted not upon successful payment, but the moment you confirm your order. The payment is then processed and your order marked as "paid" and passed on to processing.

While their approach makes sense for normal e-commerce sites, sites where the stock is limited ask for another approach. Of course, as a developer it becomes more difficult to get items out of stock once they are placed in the shopping cart, most especially because when to release the items to stock if the customer does not buy? I did find another article, explaining when retailers should empty a shopping cart. From the article i deduced some rules:

• if your stock is limited, placing items in the shopping cart should reserve the item (removing it from available stock temporarily), so you have a difference between the actual stock (what the retailer has in their storage, reserved stock (about to be sold or not) and sold stock). So the amount of stock visible on the site should be actual stock-reserved stock.
• how long your shopping cart is valid should be visible or communicated (e.g. countdown clock) I would like to note that this is especially true for ticketing services, where stock is in very limited supply and in large demand. You want to give the user the good shopping experience (when a customer puts the items in the shopping basket, there still was stock, so he or she should be able to buy them), but also not let your users hoard the stock. An excellent example from the above-mentioned article is Ticketmaster, where a user can put tickets in her basket, and then has a predefined time (two minutes) to complete the purchase or the cart is emptied and the stock released again. As a consequence, the meaning of your shopping cart is different: it is a clear intention to buy, so it will not be used as a wish list. On e-commerce sites where there is no such peak of sales, shopping carts can even persist over different sessions, allowing returning users to continue shopping. Such a use of a shopping cart would not be linked to the stock directly (e.g. reserving items), but whether an item is in stock would be checked at the start of a new session. This is in high contrast with an e-commerce site offering items which are in very limited supply and high demand (like tickets or instant film). The standard approach does not suffice. If putting items in the shopping basket takes them out of the stock, the load can be spread more evenly. Let me explain that by example, by comparing 2 scenarios. Scenario 1, the standard e-commerce site, items are only taken out of stock after an order is confirmed:
• 1000's of people log on
• all of them add a number of items to their shopping basket
• all of them start filling in their details, payment methods, delivery address, and all this has to be verified, connections to Paypal, credit-card service, ...
• in the meantime no items have been sold, so users logging on can still start buying things, thereby adding more load to the server, ...
• the server bends under the escalating load Now compare this to scenario two, where items are being "reserved" if they are put inside the shopping basket, and a user has two minutes to complete the order-confirmation process:
• 1000's of people log on
• 400 or more of those people get rejected, because the items have been reserved
• the users who were able to get items in the basket, fill in the details, which have to be verified, ...
• users logging on later will in the meantime not be able to order anything, because all items have been reserved
• after the first two minutes have passed, most of those first items will have been bought, and some will have released again
• some users will be able to fetch released items and can continue shopping This scenario will not only communicate better to your clients, the process is clearer, AND the load on your servers can't escalate in the same way. This process could then be further improved, so that users logging on are placed in a FIFO queue. The first users to place an order get their items until stock runs out. The following ones are placed in a waiting queue, and busy-wait at most the two minutes (the maximum time before items could be released) for those that are released, if any. If a user has no patience, he releases his place in the queue. If you add to that some real-time communication (pushing to the client?), you would have a real clean a user-friendly system. From the moment a user logs on, it is clear what is going on.