Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
What is the best practice to manage the case where two customers add in the same time a product whose the stock was only 1 ?
Must there be a check in the code of the basket to avoid one of these 2 customers to add the same product ?
Or does this check must be carried out in the payment phase in doing for instance a second query to confirm the concerned product is still present in stock (means not bought yet by the concurrent customer) ?
There is no perfect answer for this question and all depends on details.
As a first 'defense line' I would try to avoid such situations at all, by simply not selling out articles that low if any possible. If this is possible may depend on the situation and the kind of articles you want to sell. In the company I work, articles are mostly removed from the website before we run out of stock. But we are selling whole sale and the few remaining articles are sold by our sales people as special offers. This may not be an option for small shops, especially when selling high priced articles.
The solution to do the double check when adding something to the basket isn't very good. People put a lot in baskets without ever actually placing an order. So this may block this article for a certain period of time.
So in my humble opinion for small jobs the best way is to do a final check right before the payment, when the order is actually placed. In worst case you have to tell you customer that you where running out of stock right now (what for small shops will not happen that often).
I think best practice is to choose which of below options is more appropriate for particular business case:
...solves this problem (problem of session conflict) by validating that the changes about to be committed by one session don't conflict with the changes of another session. A successful pre-commit validation is, in a sense, obtaining a lock indicating it's okay to go ahead with the changes to the record data. So long as the validation and the updates occur within a single system transaction the business transaction will display consistency...
This is a people problem, as well as a database problem, the database locking is the easy bit!
Given that a customer may never check out…
You have two basic options:
You reserve an item for the customer for a fix time say (20 minutes) after they have added it to the basket – after they time they have to recheck the stock level or start again. This is often used to ticket to events or airline seats.
Or you say something like “xxx normal despatched in 24 hours”, but reserve the stock when they checkout, in this case you must allow them to cancel the order after checkout if some items are in stock but not others. (Green, Yellow, Red stock levels can also work well, or some website say “low stock” when they are down to 1 or 2)
In our case, we used message queue to handle orders and configured it such that it only processes one job at a time in sequence on the same product, in a FIFO fashion.
The caveat is that you're adding a new overhead to the whole ordering processing which delays things a bit.
As always, it depends on what your requirements are. If you are Amazon and sell 100,000,000 items per day, the overhead for preemptive checking and locking is probably prohibitive, and the problem of one customer per day not getting their item after all is negligible. It you deal in rare antique religious icons that are unique and expensive, the opposite probably applies. You yourself must know where your business case is located on that spectrum.
The best practice, for the user, is obviously to make sure the second add fails. But this is going to slow your whole site down for the sake of the 0.1% case.
The most technically efficient solution, and the one to maximise sales, is to allow it to succeed and then try to fulfil both orders later -- just cause you don't have stock right now, doesn't mean you can't find it in an emergency. If you can't then someone has to contact the user who lucked out and apologise. But that is exactly what led to uproar before Christmas this year (this is not the only article that appeared, so apologies to Best Buy but it was the first I found).
Your job is to present all the options to the business, with pros and cons, and let them decide based on your advice. If they can afford an occasional small hit to reputation to maximise sales then fair enough; if they can't and traffic is so low that you can check for double-updates quickly then that's also their call.
