🚗 Race Conditions, what can we do?

Hey everyone, we are running into an issue that I feel is extremely common - race conditions.

So the situation is simple:

  1. There is a product.
  2. Two (or three) try to buy the same product at nearly the same time.
  3. All three of them get the product in their shopping cart.
  4. There was only 1 of the product. Who gets it?

Essentially we have tried to reduce the “stock” of the item when an item is purchased, but what ends up happening is that the stock of the item does not change fast enough.

We have tried scheduling API workflows at random intervals in the future, but this is at best a temporary fix (and slows down the app a lot), and it doesn’t even work all the time.

In general programming I know that we would use a lock condition, but is there a way to “lock” the resource when it is being edited that isn’t also susceptible to the same issue?

This is happening on an auction site: when an item is dropped, all users see it at nearly the same time, and a lot of people are racing to claim it. Definitely not a fringe case, and this happens all the time.


could you reduce stock when an item enters the shopping cart?

Unfortunately no, as users can have it entering their shopping cart at the same time.

Put a field onto the shopping cart data type that would be a date field to see what time they actually pressed it down to the millisecond (I believe Bubble date type is that accurate) and if you have a situation with multiple users who put into cart ‘at the same time’ I’m sure the milliseconds will matter and use that to determine who gets it since they would be the first.

Setup some message to show to all the losers and explain that they were how many milliseconds away and to next time be faster…that might help build up some demand and create that buzz from scarcity.


Yes, a typical inventory management issue. Seems like you have to be able to reliably keep track of:

  1. The number of items in inventory, which gets reduced once a product is purchased
  2. The number of items available to be purchased, which is inventory minus what is in carts.

Each time a user moves a product to the cart, the system needs to check first if any are available (>0). If so, immediately decrement the “available” count. Otherwise, notify user the product is currently unavailable.

Maybe the system would be fast enough to manage the count that way? You could test that pretty simply in a separate app. Otherwise, seems like you’d need to implement a locking mechanism of some sort as you suggested. Not sure the best way to do that…

Thanks for the reply!

I think the question really becomes, how do I check if there were more than one in order to compare?

This is essentially along the same lines as what I tried, where every purchase would schedule a future workflow (a random number between 2-6 seconds later) to “check” whether there are more orders than stock, and if there were, sort them by date and delete the older ones, sending a message to those users notifying them that they were x amount of seconds slower.

I’m not entirely sure why, but in all of my iterations of this, it was never reliable – it would work about 20% of the time. Every so often it would schedule both API workflows at the same time, which would end up deleting more orders than it should have, or sometimes not deleting any.

Thanks for the reply!
This was my first try - when it checks both at nearly the same time what will happen is that both workflows will pass the condition, then the first workflow (by x milliseconds) will reduce the stock by 1 (2-1=1) and the second workflow one would do the same, but it was reading the previous value of stock (2-1=1) and so 2 orders at the same time would always produce a 1. Classic race condition.


As already mentioned above you’ll need to use time of bid as priority and not the number of stock of the products.

At point of click create orders and time of bid and then try to fulfil them on a basis of first time first gets. You can hide the bid button immediately the number of orders exceeds the stocks.

Then evaluate in order of priority who gets the bid and who lost.

Hope that help.

Probably based on the conditions you put onto those workflows.

Hello @justin.hume.

I have just released a plugin that you might find useful to solve race conditions:

If you have any questions, please let me know.


If you search for “Optimistic Offline Lock” you should find how to do virtual locking.

You don’t really need an actual lock most of the time.

If I’m not mistaken, “optimistic locking” is what @justin.hume was trying to achieve, but it’s not perfect, hence the issues he was having.

This plugin actually achieves “pessimistic locking”, which would solve the issues one encounters in “optimistic locking”.

So in summary, you might not really need an actual lock most of the time, but sometimes you do need them.

This topic was automatically closed after 70 days. New replies are no longer allowed.