Preventing Overselling in WooCommerce Flash Sales: Database Locks vs Inventory Caches
During high-concurrency flash sales, race conditions between cart and checkout can sell the same item twice. Here is how atomic database locking solves it.
On this page
The High-Concurrency Inventory Dilemma
During a high-profile flash sale, thousands of shoppers can hit checkout within seconds. Standard WooCommerce architecture reads the stock quantity on page load and validates it again only when the checkout form is submitted.
If two customers submit their orders within milliseconds when only one unit remains, both transactions pass the validation check before the first write finishes. Result: two successful payments for one unit, leading to disappointed customers and manual refunds.
Why In-Memory Caches Aren’t Enough
Redis or Memcached stock counters can reduce read load, but cache-to-database synchronization under network latency still creates subtle split-brain race conditions. For mission-critical inventory, we need an atomic database primitive.
Atomic Reservation with MySQL GET_LOCK
By issuing a named lock: SELECT GET_LOCK('wc_stock_{product_id}', 5); inside a database transaction, WooCommerce threads queue deterministically. The first shopper claims the unit and decrements the counter; subsequent threads instantly see zero remaining stock and receive a polite ‘Item reserved by another shopper’ notification.
Automated Timeout Cleanup
Locks must never hold inventory indefinitely. If the user closes the tab without completing checkout, an Action Scheduler event releases the reservation after 10 minutes, returning the stock to circulation seamlessly.
