How Redis Enables Ultra‑Fast Flash Sale Handling

Flash Sale Load Characteristics

Flash‑sale items have stock far lower than the number of users, resulting in two load traits: extremely high instantaneous concurrency and a read‑heavy, write‑light pattern. Traditional relational databases handle only thousands of QPS, while Redis can sustain millions, so Redis is placed in front of the DB to filter requests.

Instantaneous Concurrency

When a surge of requests arrives, Redis intercepts most of them, preventing the DB from being overwhelmed.

Read‑Many Write‑Few

Clients first read the remaining stock (a simple KV read). Only when stock is available does the system decrement the stock and create an order. A local “stock‑zero” flag can be cached to avoid unnecessary Redis reads.

Flash Sale Phases

Pre‑Sale

Users repeatedly refresh the product page, causing a spike in page‑view traffic. Static assets should be pre‑rendered and served via CDN or browser cache, keeping most requests off the back‑end.

During Sale

Each click on the “秒杀” button triggers a stock‑check request. If stock exists, the system immediately decrements it, then creates an order for payment and logistics. The dominant load is the stock‑check operation, which must be performed against Redis.

Stock check

Stock decrement

Order processing

Only when the stock check succeeds are the subsequent steps executed, so ensuring atomicity between check and decrement is critical.

Redis‑Based Stock Decrement

After a successful stock check, decrement the stock in Redis immediately. Atomicity is typically achieved with a Lua script or a distributed lock.

Two fields are stored per product in a Redis hash:

key: itemID
value: {total: N, ordered: M}

Atomic stock check and decrement using Lua:

-- Get stock info
local counts = redis.call("HMGET", KEYS[1], "total", "ordered")
local total = tonumber(counts[1])
local ordered = tonumber(counts[2])
if ordered + ARGV[1] <= total then
    redis.call("HINCRBY", KEYS[1], "ordered", ARGV[1])
    return ARGV[1]   -- success, return requested quantity
end
return 0               -- failure

The client invokes the script with EVAL (or EVALSHA) and interprets a non‑zero return as success.

Post‑Sale

After the sale ends, traffic drops sharply. Remaining users may still refresh the page to see if stock reappears, while successful purchasers check order status. The system can comfortably handle this reduced load.

Redis Features Supporting Flash Sales

High Concurrency

Redis naturally handles massive concurrent connections. For multiple flash‑sale items, a sharded cluster can distribute each product’s stock hash across different instances, avoiding a single‑point bottleneck.

Atomic Operations & Distributed Locks

Redis provides atomic commands and the ability to implement distributed locks, ensuring that stock checks and decrements are performed safely under contention.

Distributed Lock Implementation

Clients acquire a lock on the product ID before performing stock operations. Example pseudo‑code:

// Acquire lock
local lockKey = "lock:" .. itemID
local lockVal = clientID
local lockAcquired = acquireLock(lockKey, lockVal, timeout)

if lockAcquired then
    -- Stock check and decrement (Lua script or HINCRBY)
    local result = redis.call("EVALSHA", sha1, 1, itemID, qty)
    releaseLock(lockKey, lockVal)
    if result > 0 then
        -- Proceed with order creation
    else
        -- Stock exhausted
    end
else
    -- Lock not obtained, reject request early
end

Using locks filters out most requests early, reducing pressure on the stock‑storage instance.

Practical Recommendations

Deploy Redis in a sharded cluster; separate lock keys and stock keys across instances.

Do not set expiration on stock keys to avoid cache‑penetration issues.

Isolate flash‑sale Redis instances from regular business data.

Static‑ize front‑end pages and leverage CDN/browser caching before the sale starts.

Implement request filtering and rate‑limiting at the entry layer to block malicious traffic.