How to Build a High‑Performance Flash‑Sale System with Redis Caching and CDN

Flash‑Sale Characteristics

Flash‑sale (秒杀) activities sell scarce or discounted items at a fixed time and quantity, attracting massive numbers of consumers. Within a very short window the page‑view and order‑request traffic can be tens or hundreds of times higher than normal, creating three distinct phases:

Pre‑sale: Users continuously refresh the product detail page, causing an instantaneous peak of page requests.

Sale start: Users click the “Buy Now” button, generating a peak of order requests.

Post‑sale: Successful purchasers keep checking order status or canceling, while the majority continue refreshing the page hoping for a chance.

System Architecture Overview

The core idea is to filter out as much invalid traffic as possible before it reaches the database by leveraging a layered architecture.

1. Browser Cache and CDN for Static Page Traffic

Separate the flash‑sale product page from regular product pages. All static elements (images, CSS, HTML) are cached in the browser and on a CDN, while only the “Buy” button requires a server‑side check. This reduces the amount of traffic that actually hits the backend during the pre‑sale phase.

2. Read‑Write Split Redis for Traffic Throttling

Use a Redis cluster that supports read‑write separation as the second layer of traffic control. Product information and a start flag are pre‑loaded into Redis:

{
  "goodsId_count": 100, // total stock
  "goodsId_start": 0,   // start flag (0 = not started, 1 = started)
  "goodsId_access": 0   // number of successful orders
}

Before the sale, services read goodsId_start; if it is 0 they return “not started”.

When the sale begins, the control module sets goodsId_start to 1.

Services cache the start flag and begin accepting requests, incrementing goodsId_access for each successful order. Remaining stock = goodsId_count - goodsId_access.

When goodsId_access reaches goodsId_count, all further requests are rejected because stock is 0.

3. Lua Script for Atomic Stock Decrement

To guarantee atomicity of stock checks and updates, a Lua script is stored in Redis. Because Redis executes Lua scripts single‑threaded, the sequence of commands is atomic.

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 loaded once with SCRIPT LOAD to obtain a SHA1 hash, then invoked for each order using EVALSHA, which saves network bandwidth compared with EVAL.

4. Redis as a Simple Message Queue for Asynchronous Order Persistence

After stock is successfully decremented, the order is pushed into a Redis list, acting as a lightweight message queue. A background consumer asynchronously pops orders and writes them to the database, avoiding direct DB writes during the high‑traffic window.

LPUSH orderList {order_content}

BRPOP orderList 0

This approach dramatically reduces database lock contention and improves order‑completion speed.

Conclusion

By combining CDN‑cached static pages, a read‑write split Redis layer for early traffic filtering, Lua‑based atomic stock deduction, and Redis‑backed message queues for async persistence, the flash‑sale system can handle extreme concurrency, maintain fairness, and protect the underlying database from overload.