How to Prevent Overselling With Atomic Stock Booking

Overselling almost never happens because a stock count was wrong. It happens because two requests for the last unit ran at almost exactly the same time, and the system checked stock before either one had actually claimed it. By the time both requests finish, one sale is legitimate and one is a promise the business can't keep: a cancelled order, a refund, and an apology email, sent hours or days after the customer thought they'd bought something.

Why the obvious approach breaks

Most systems that oversell are running logic that looks reasonable in isolation:

That's fine for exactly one request at a time. It fails the moment two requests interleave: both read "1 remaining" in step 1 before either has written anything back in step 3. Both see stock available, both proceed, and the database ends up with -1 units sold against 1 in stock. Nobody wrote a bug here. The read and the write were just two separate steps, and something else got to run in between them.

This is a race condition, and it gets more likely, not less, as traffic grows. A low-traffic storefront might go months without hitting it. A flash sale, a popular marketplace listing, or a reseller's storefront hitting the same low-stock item at the same moment as your own site will find it reliably.

What atomic booking does differently

An atomic stock booking collapses "check" and "decrement" into one indivisible database operation, something closer to UPDATE products SET stock = stock - :qty WHERE id = :id AND stock >= :qty than two separate steps. The database itself guarantees no other write can land in the middle of that statement. Either the update matches a row and reduces stock, or the guard clause fails and it doesn't. There's no window where two callers can both believe they succeeded.

The practical result: when two shoppers race for the last unit, exactly one booking succeeds and the other gets a clear, immediate "insufficient stock" response, instead of a cancelled order two days later. The failure moves from "silent and expensive" to "instant and honest."

What this means for an integration

• Never implement your own "check then write" against a product feed's stock count from your own code. Even if it looks harmless, it reintroduces exactly the race condition an atomic booking endpoint exists to close.
• Treat a booking rejection as a normal, expected response, not an error to retry blindly. It usually means someone else legitimately got there first.
• A reference number on every booking (so you can reconcile against your own order records) matters more once bookings are coming from more than one channel at once.

How Feedwyre handles this

Every booking against a Feedwyre feed goes through one atomic operation that checks and decrements stock in the same database statement, whether the request came from your own storefront, a reseller's child feed, or a partner's integration. Two simultaneous requests for the last unit can't both succeed, and every booking gets a reference number and shows up in the feed's activity log, so reconciling "what actually sold, from where" doesn't require guesswork.