Overselling is not a website bug — it is an architecture decision. When the counter, the marketplace and the online store each keep their own stock, drift is guaranteed.
Most retailers run at least three stock records: the one in the billing software, the one in the ecommerce platform, and the one in somebody's head. Sync jobs paper over the gap until a festival weekend, when the last unit sells twice and one customer gets a refund instead of a parcel.
The instinct is to fix this with better syncing. Faster jobs, tighter webhooks, a reconciliation script that runs at midnight. That treats the symptom. The cause is that two systems each believe they own the number.
Sync is a promise that degrades
Every sync has a window. Between the sale at the till and the moment the website learns about it, the website is wrong. On a quiet Tuesday that window is harmless. On a sale weekend, when orders arrive faster than the window closes, it is precisely when it hurts.
It also fails asymmetrically. A goods receipt that has not synced means you are sitting on stock you could be selling. A sale that has not synced means you are selling stock you no longer have. The second one costs you a customer.
One ledger, many channels
The alternative is to treat inventory as a single ledger held per outlet and per warehouse, with every channel drawing down from it directly. The counter, your website, a marketplace listing and a mini app are all readers and writers of the same record.
A sale stops being an event to reconcile later and becomes a movement in the ledger at the moment it happens. There is no window, because there is no second copy to fall behind.
The same holds in reverse. A goods receipt at the warehouse is immediately sellable everywhere. A stock adjustment after a physical count is a recorded, attributable movement rather than a mystery delta between two systems that never quite agreed.
What this costs you to get right
The practical requirement is that your website reads stock from the system that bills, rather than holding its own catalogue. That is a build decision made once, at the start, and it is much harder to retrofit after you have two catalogues and a year of divergence between them.
It is also the reason we build storefronts against live data rather than exporting a product feed. One catalogue, one stock position, and no reconciliation job to babysit.