I’m trying to create a simple flash sale page, which have mutiple items with limited amount of it. Users can log in and buy the item they like with their own point. When a user click the buy button, it will check the stock, if stock is above 0, it will proceed to reduce stock buy 1 and create a new record in a new table. However, if there are many users trying to click the buy button at the same time, the systems can’t seem to check the stock correctly, and all user can buy it even stock is only 1 or 2.
Can anyone help me on this? Here’s the Buy button action for your reference. thank you a lot
Ya, this is a common issue in Glide without a great native solution because of the delay between new data being registered to other users (because data calculations occur on the user’s device and not on Glide’s servers). @Darren_Murphy proposes sending these requests to a service like Make where it can handle the race issue more fairly, but to be honest, he’d have to speak on that because I’ve never implemented such a feature.
Yeah, only way to deal with this that I’m aware of is to use something like Make to queue the requests.
Two ways you could approach it, I think.
The first would be that Make would need to maintain a separate count of stock levels - probably in a Data Store - and then as each request comes in (via a webhook), it would first check the stock levels, and then if there were sufficient stock levels, process the request (API call), and then adjust it’s own stock level after getting a successful response from Glide.
The second would be for Make to use an API call to check the stock levels before processing each request. This one would require a Business Plan or better, and would be less efficient as it would double the number of API calls.
Either way, because the requests would be queued by Make and handled serially, it should eliminate the possibility of over ordering.
