implementing a locking/checking mechanism for stock quantity when users concurrently buy the same thing

Question

im new to this so please forgive any mistakes. im building an ecommerce platform to sell certain goods. i want to ensure that if multiple users buy the same product at around the same time. the user should not be allowed to go to payment if enough stock is not available. the problem is im not decreasing the stock from the database until payment is successfully made.while one user makes a payment to the others the stock might still appear full and they could in turn place orders for stock that doesnt exist. I just need some direction to implement some kind of locking mechanism for product stock under processing. like how while booking movie tickets the seat is blocked until the transaction completes else it is released.I want to implement the same for stock. any ideas? Im using asp.net C#

Possible duplicate of [How to deal with inventory and concurrency](http://stackoverflow.com/questions/6670164/how-to-deal-with-inventory-and-concurrency) — Korayem, Dec 20 '16 at 13:54

score 2 · Answer 1 · answered Jun 25 '15 at 07:48

2

the solution i found was to reduce the stock quantity before going to the payment gateway and keep a timer which puts the stock back on after timer elapses only if payment is not successful.

answered Jun 25 '15 at 07:48

Sujit.Warrier

2,815
2
28
47

nikib3ro · Accepted Answer · 2015-06-19T05:05:32.740

Well, the reason why you can't come up with solution is because you don't have implementation, but rather business problem.

Once business policies are defined, implementation will be easy.

For example, Amazon allows ordering or products that are running out by saying "we'll deliver in 2-4 weeks". Meaning, you can still order, you'll just get product later / emailed once it's on the way.

In your case, however, if you have finite resources (seats / movie tickets) - you can start putting people in waiting list. Like, warn them that you are running out of seats, but allow them to complete process normally. Then as you are processing payments, you can send more detailed emails to those who are left without seat. Kinda like airlines do. Once you sort out those who really bought tickets refund those who are left without seats.

If your problem is deeper (like you are thinking about blocking individual seats) - definitely think more about business policies. Like, do you really need to go down that level? Can't you do what airlines are doing (sell tickets for certain class first, and then later allow users to pick seats)? Again - core of your problem is business, rather than implementation. Once use cases are properly defined, you'll probably just need to use standard database locks.

The most important thing in processes like this is transparency. Be honest with your users. Keep them informed through the process and don't try to trick them - like show more seats that there really is, just to incentify them to complete the purchase.

With some kinds payment (including credit cards) you can do a preauth and cancel it, instead of an actual payment which you then cancel. — CodesInChaos, Jun 25 '15 at 07:54

score 0 · Answer 3 · answered Dec 20 '16 at 13:53

In my case, I used message queue (Hangfire) to handle orders and configured it such that it only processes one job at a time in sequence on the same product. FIFO style.

Notice that you're adding a new overhead to the whole ordering processing which delays things. Need to re-architect resources to minimize that time.

implementing a locking/checking mechanism for stock quantity when users concurrently buy the same thing

3 Answers3