Inventory Deduction Strategies for Flash Sale (秒杀) Systems

This article examines three inventory‑deduction approaches for flash‑sale scenarios, discusses methods to mitigate malicious buyers, addresses payment‑failure due to insufficient stock, presents database‑level solutions to prevent overselling under high concurrency, and explores practical implementations using order‑time deduction, Redis caching, and rate limiting.

Wukong Talks Architecture
Wukong Talks Architecture
Wukong Talks Architecture
Inventory Deduction Strategies for Flash Sale (秒杀) Systems

Hello, I am Wukong. In the previous article we talked about flash‑sale design solutions; today we explore inventory‑deduction schemes.

1. Three Inventory‑Deduction Schemes

1.1 Deduct Inventory at Order Placement

Inventory is reduced when the user places an order.

Advantages: Real‑time inventory reduction, avoiding stock‑shortage issues during payment.

Disadvantages: Malicious buyers can place many orders without paying, exhausting stock for genuine customers.

1.2 Deduct Inventory at Payment

The order page shows the latest stock, but inventory is only reduced when payment succeeds.

Advantages: Prevents malicious buyers from exhausting stock by ordering without paying.

Disadvantages: The displayed stock may be stale; if the stock runs out after the page is shown, orders may exceed available inventory, leading to payment failures.

1.3 Pre‑Deduct (Reservation) Inventory

The order page shows the latest stock; after ordering, the reserved stock is held for a period (e.g., 10 minutes) and released if not paid.

Advantages: Combines real‑time reduction with protection against malicious bulk orders; un‑paid reservations are released.

Disadvantages: During the reservation window, malicious buyers can still exhaust stock, and high concurrency may still cause orders to exceed stock.

2. Dealing with Malicious Buyers

Malicious buyers are those who place a large number of orders in a short time to consume all inventory.

2.1 Limit Quantity per User

Advantages: Restricts malicious ordering.

Disadvantages: Legitimate users who want multiple items may be limited, reducing sales.

2.2 Identify Malicious Buyers

By marking device IDs or member IDs and adding them to a blacklist; however, some users may spoof identifiers, making detection imperfect.

3. Solving Order‑Success but Payment‑Failure Due to Insufficient Stock

3.1 Spare Inventory

If the main stock is exhausted but users still attempt to pay, deduct from a spare inventory.

Advantages: Mitigates some payment failures.

Disadvantages: Only a temporary fix; for low‑stock items spare inventory is limited, and many users may still experience failures.

4. Preventing Overselling Under High Concurrency

Overselling occurs when multiple orders are processed simultaneously, causing the final stock count to be incorrect.

Users A and B both see stock = 10, place orders, and attempt payment at the same time.

Both callbacks execute concurrently: inventory = 10 Thread A updates: lastInventory = inventory - 1 = 9 Thread B also updates: lastInventory = inventory - 1 = 9 The correct final stock should be 8, leading to oversell.

Solution 1

Update inventory directly with a single SQL statement instead of a read‑modify‑write cycle.

UPDATE [inventory_table] SET stock = stock - 1

Solution 2

When updating, if the resulting stock becomes negative, throw an exception; the transaction will roll back automatically.

Solution 3

Update only when the stock after deduction remains non‑negative and check the affected row count.

UPDATE [inventory_table] SET stock = stock - 1 WHERE stock - 1 > 0

If the affected rows > 0, deduction succeeded; otherwise, do not update and refund the order.

5. Inventory Deduction in Flash‑Sale Scenarios

5.1 Use Order‑Time Deduction

Because most flash‑sale users intend to purchase immediately, deducting at order placement is simple and effective; malicious buyers do not gain extra advantage in this context.

5.2 Use Redis Cache

Cache the stock count for faster reads and decrement directly in Redis. Under extreme concurrency, a distributed lock can be applied (see my previous articles on Redis distributed locks).

5.3 Rate Limiting

Apply front‑end and back‑end rate‑limiting (e.g., token bucket) to reduce the number of requests that actually reach the inventory‑deduction stage.

In real projects, many additional mechanisms are combined to ensure reliable stock deduction; this article provides an introductory overview and invites further suggestions.

Below is a summary diagram of flash‑sale inventory strategies:

Recommended reading: I am a flash‑sale request, escaping this planet...

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

inventorydistributed-lockflash sale
Wukong Talks Architecture
Written by

Wukong Talks Architecture

Explaining distributed systems and architecture through stories. Author of the "JVM Performance Tuning in Practice" column, open-source author of "Spring Cloud in Practice PassJava", and independently developed a PMP practice quiz mini-program.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.