Designing a High‑Concurrency Flash Sale System Using Cloud Redis Caching

Flash‑sale (秒杀) activities are a common low‑price promotion method for e‑commerce platforms, generating massive page views and order requests in a very short time; a well‑designed system improves stability, fairness, and user experience.

The article discusses the design of a high‑concurrency flash‑sale system based on the cloud Redis database.

Flash‑sale characteristics : limited‑quantity items are sold at a scheduled time, causing traffic spikes in three phases – pre‑sale page refreshes, sale start order bursts, and post‑sale order/status checks.

Traditional row‑level locking in databases cannot handle such load, often leading to service blockage.

System architecture : By separating static and dynamic parts of the product page, static resources are cached in browsers and CDNs, reducing server traffic before the sale starts.

Read‑write split Redis for traffic interception : Before the sale, product data is pre‑loaded into a read‑write split Redis instance with a start flag.

"goodsId_count": 100 // total
"goodsId_start": 0   // start flag
"goodsId_access": 0  // accepted orders

The workflow is:

Before the sale, services read goodsId_start = 0 and return “not started”.

The data‑control module sets goodsId_start to 1 to mark the sale start.

Services accept requests, increment goodsId_access , and compute remaining stock as (goodsId_count - goodsId_access) .

When goodsId_access reaches goodsId_count , all further requests are blocked.

Master‑slave Redis for inventory deduction : Successful orders are processed using a master‑slave Redis hash to store inventory, avoiding direct database hits.

"goodsId": {
    "Total": 100,
    "Booked": 100
}

The atomic deduction is performed with a Lua script:

local n = tonumber(ARGV[1])
if not n or n == 0 then
    return 0
end
local vals = redis.call("HMGET", KEYS[1], "Total", "Booked")
local total = tonumber(vals[1])
local booked = tonumber(vals[2])
if not total or not booked then
    return 0
end
if booked + n <= total then
    redis.call("HINCRBY", KEYS[1], "Booked", n)
    return n
end
return 0

The script is pre‑loaded with SCRIPT LOAD and invoked via EVALSHA to save bandwidth:

redis 127.0.0.1:6379> SCRIPT LOAD "lua code"
"438dd755f3fe0d32771753eb57f075b18fed7716"
redis 127.0.0.1:6379> EVALSHA 438dd755f3fe0d32771753eb57f075b18fed7716 1 goodsId 1

If Redis returns a non‑zero number, the order deduction succeeded.

Redis‑based message queue for asynchronous order persistence : After deduction, orders are pushed into a Redis list acting as a queue, allowing a separate consumer to write them to the database without blocking the sale flow.

orderList {
    [0] = {order content}
    [1] = {order content}
    ...
}

LPUSH orderList {order content}

BRPOP orderList 0

This asynchronous processing improves order completion speed and reduces database lock contention.

Data‑control module synchronization : Periodically syncs calculated data from the primary database to both master‑slave and read‑write split Redis instances, ensuring that more traffic can be admitted as the sale progresses.

(End)