How to Build a High‑Throughput Flash‑Sale System Without Overselling

Scenario

Flash‑sale (秒杀) typical use cases include e‑commerce discount events, red‑packet grabs, and ticket purchases. Example: three products, each with 1,000 units, and one million users compete for the items.

Requirements

Never oversell – inventory must never become negative.

Each purchase must decrement stock and persist an order record.

The system must handle massive concurrent requests without blocking.

Row‑level locks caused by single‑row UPDATE statements create contention.

Optimization Architecture

1. Traffic Shedding at the Web‑Server Layer

Randomly drop a configurable proportion of incoming requests (e.g., keep 1 of every 10). This reduces load and turns strict first‑come‑first‑served ordering into a lottery while still guaranteeing fairness over the retained subset.

2. Per‑Server Quota Managed by ZooKeeper

Before the sale, compute total stock per product and split it into equal quotas for each web server. Example: 1,000 units of a product across 8 servers → 125 units per server. Store the quotas in ZooKeeper; each server watches the node and updates a local counter.

private static ConcurrentHashMap<String,Integer> quotaMap = new ConcurrentHashMap<>();

private void initQuotaFromZooKeeper(){
    // Values loaded from ZooKeeper
    quotaMap.put("TV",125);
    quotaMap.put("Phone",125);
    quotaMap.put("Clothes",125);
}

When a request for “TV” arrives, only the TV counter on that server is locked, allowing other products and other servers to continue processing concurrently.

3. Dynamic Quota Adjustment

During the event, inventory may need to be reduced (e.g., stop after 500 sold) or increased (extra warehouse stock). Updating the corresponding ZooKeeper node instantly propagates the new quota to all servers, which refresh their local caches.

4. Message‑Queue with Multiple Consumers

Web servers enqueue purchase requests into a durable queue (Kafka, RabbitMQ, etc.). A pool of consumer workers pulls messages, decrements stock in the database, and writes the order record. Parallel consumers increase throughput while preventing the queue from becoming a bottleneck.

5. Stored Procedure vs. JDBC

Each consumer can invoke a stored procedure that performs the stock UPDATE and order INSERT in a single transaction. Compared with separate JDBC statements, the stored procedure reduces lock‑hold time from ~2 ms (network latency + processing) to the execution time of the procedure, improving concurrency.

6. Slot‑Based Stock Table

Split a product’s inventory into multiple “slots” (e.g., four rows). A transaction selects the slot with the highest remaining quantity, decrements it, and commits. This converts one hot row lock into up to four concurrent locks, roughly quadrupling throughput.

-- Select the slot with most stock
SELECT product, remaining, slot
FROM stock_slot
WHERE product='TV' AND remaining>0
ORDER BY remaining DESC
LIMIT 1
FOR UPDATE;

-- Decrement the selected slot
UPDATE stock_slot
SET remaining = remaining - 1
WHERE product='TV' AND slot = ? AND remaining>0;

If the UPDATE affects a row, insert the order detail and commit; otherwise repeat with another slot.

7. Hot‑Item Isolation

Place extremely popular items (e.g., a newly released iPhone) in a dedicated database or schema. This isolates their high‑frequency updates from regular products, preventing contention across the whole system.

Key Takeaways

Combine traffic shedding, per‑server quota management via ZooKeeper, and a message‑queue consumer pool to limit concurrent DB updates.

Use stored procedures to keep the critical section short.

Adopt a slot‑based inventory table to spread row locks.

Isolate hot items in separate databases to protect other workloads.