Master Flash Sale Systems: Backend Strategies for Millions of Requests

Flash‑sale business characteristics

A flash‑sale (秒杀) service presents a very small set of items that become available for purchase within a short time window. The same data is read and written by a massive number of concurrent users, creating a "swarm request" pattern.

Typical scenarios

Train‑ticket release during Chinese New Year, where millions of requests arrive simultaneously.

Launch of a hot product that sells out within seconds.

Technical challenges

Massive instantaneous traffic: the ingress, application, and data layers must sustain extreme QPS.

Atomicity and fairness: increments/decrements of inventory must be atomic and ordered to avoid overselling.

Data safety: protection against attacks, request flooding, and ensuring idempotent operations.

Concurrent control: preventing deadlocks when many threads compete for the same resources.

Optimization techniques

1. Early request filtering

Filter invalid or abusive requests on the client side (Web front‑end or mobile app) to reduce load on backend services.

Login interception : reject unauthenticated users.

Duplicate submission interception : disable the submit button until a response is received or a timeout (e.g., 5 s) occurs, guaranteeing idempotency.

Frequent submission interception : limit each user to a maximum of 100 requests per minute to curb bots.

Captcha interception : require a verification code for suspicious traffic.

Eligibility interception : preload a whitelist and reject users who do not meet criteria such as minimum account age, level, or blacklist status.

2. Server + cache layer for efficient atomic operations

Caching hot data with Redis dramatically reduces database pressure. A single Redis instance can handle ~100 k operations per second; clustering and replication increase capacity further.

Redis provides built‑in atomic counters:

INCR   key          # increment by 1
INCRBY key N        # increment by N
DECR   key          # decrement by 1
DECRBY key N        # decrement by N

Example: increase the sold count by 1 000 units.

# Increment sold count
INCRBY cullinan_counter 1000
# Retrieve current count
GET cullinan_counter

For a conditional check (e.g., reject the request if the count exceeds the inventory limit), use a Lua script evaluated atomically:

local cur = tonumber(redis.call('GET', 'cullinan_counter'))
if cur > 1000 then
    return false   -- sale fails
else
    return true    -- sale succeeds
end

In Go:

result, err := client.Eval(ctx, `
    local cur = tonumber(redis.call('GET', 'cullinan_counter'))
    if cur > 1000 then
        return false
    else
        return true
    end
`, []string{}).Result()

To preserve request order, use Redis Streams. Each XADD call appends a message with a unique ID. XADD mystream * field1 value1 field2 value2 If the inventory is limited to 1 000 units, the 1 001st request can be discarded before it enters the stream.

3. Database as the final safeguard

After the cache layer, the remaining write load on the database is small. Use a constrained UPDATE to ensure stock never exceeds the limit.

UPDATE products
SET stock = stock + 1
WHERE id = ? AND stock < 1000;

4. Regional isolation for global deployments

Deploying a single cache or database across regions introduces latency unfairness (e.g., European users may lose the race to Chinese users). The common practice is to isolate units by region or data‑center, each with its own Redis cluster and configuration, and synchronize only the static product catalog.

Key takeaways

Filter invalid requests as early as possible, preferably on the client side.

Leverage Redis for high‑performance lookups, atomic counters, and ordered streams.

Use the database as a safety net with constrained updates to prevent overselling.

Apply divide‑and‑conquer: isolate regional units to avoid a single point of contention.