Design and Implementation of a High‑Concurrency Flash Sale (Seckill) System

Author: Tao Bangren (Source: my.oschina.net/xianggao/blog/524943)

Hello, I am a senior architect.

1. Flash‑sale Business Analysis

Normal e‑commerce flow

(1) Query product;
(2) Create order;
(3) Decrease inventory;
(4) Update order;
(5) Pay;
(6) Seller ships

Flash‑sale characteristics

(1) Low price;
(2) Massive promotion;
(3) Instant sell‑out;
(4) Usually timed release;
(5) Short duration, high instantaneous concurrency

2. Flash‑sale Technical Challenges

Assuming a flash‑sale of a single item attracts 10,000 participants, the maximum concurrent request count is 10,000, posing several challenges:

Impact on existing website services

The flash‑sale adds a short‑term, high‑concurrency load that can overwhelm the existing system if deployed together, potentially causing a complete site outage.

Solution: Deploy the flash‑sale system independently, possibly using a separate domain to isolate it from the main site.

High‑concurrency load on application and database

Frequent page refreshes before the sale cause massive requests to the application server and database, creating severe load pressure.

Solution: Staticize the flash‑sale page so that requests bypass the application server.

Sudden increase in network and server bandwidth

If each product page is ~200 KB, 10,000 concurrent users require ~2 GB bandwidth, which becomes a bottleneck.

Solution: Cache the flash‑sale page in a CDN and rent additional outbound bandwidth.

Direct order URL exposure

If the order URL is known before the sale starts, users can bypass the timing restriction.

Solution: Dynamically generate the order URL with a server‑side random parameter that is only available after the sale begins.

Control of the purchase button state

The button should be gray before the sale and become active only when the sale starts. Since the page is static and cached, the button state is controlled via JavaScript that updates a flag and the order URL.

Solution: Use a small JavaScript file that toggles a flag and injects the randomized order URL; version the script to avoid CDN caching.

Ensuring only the first successful order is processed

Only the first order should be sent to the order subsystem; subsequent orders should see a sale‑ended page.

Solution: Limit each server to a small number of concurrent order requests and use cookies or a least‑connection load‑balancing algorithm to reduce overload.

Pre‑order checks

Check the number of orders processed by the current server; reject if over limit.

If the total submitted orders exceed the inventory, reject further requests.

Timed product release

Set a fixed release time; hide the “Buy Now” button until the sale starts, but protect the URL with server‑side verification.

Inventory reduction strategies

Two approaches: reduce inventory on order placement or on payment. The “reduce on order” method provides a better user experience.

To avoid overselling, use optimistic locking:

update auction_auctions set quantity = #inQuantity# where auction_id = #itemId# and quantity = #dbQuantity#

Or try‑decrement method:

update auction_auctions set quantity = quantity-#count# where auction_id = #itemId# and quantity >= #count#

3. Flash‑sale Architecture Principles

Intercept requests as early as possible

Most requests get blocked before reaching the backend data layer, preventing overload.

Read‑heavy, write‑light pattern

Cache reads heavily; writes are rare, making caching an ideal solution.

4. Flash‑sale Architecture Design

The system is dedicated to flash‑sale, focusing on fast page refreshes and minimal user‑experience details.

The purchase button lights up only when the sale starts; the order form allows only a single quantity and uses default address/payment settings.

The process is divided into two phases: preparation (before the sale) and the actual flash‑sale phase.

4.1 Front‑end Design

Display the flash‑sale product page with a countdown timer. Static resources should be stored separately and served via CDN to handle massive bandwidth.

Synchronize client and server clocks to avoid timing discrepancies.

4.2 Site‑level Design Limit request frequency per UID and per item, caching responses for a short period. 4.3 Service‑level Design Use Nginx/Apache for request distribution, pre‑process requests to filter out-of‑stock items, and queue valid requests for database processing. package seckill; import org.apache.http.HttpRequest; /** * Pre‑process stage: reject unnecessary requests, queue necessary ones. */ public class PreProcessor { private static boolean reminds = true; private static void forbidden() { /* Do something */ } public static boolean checkReminds() { if (reminds) { if (!RPC.checkReminds()) { reminds = false; } } return reminds; } public static void preProcess(HttpRequest request) { if (checkReminds()) { RequestQueue.queue.add(request); } else { forbidden(); } } } Choose an appropriate concurrent queue (e.g., ConcurrentLinkedQueue) based on the high enqueue‑low dequeue pattern. package seckill; import java.util.concurrent.ConcurrentLinkedQueue; import org.apache.http.HttpRequest; public class RequestQueue { public static ConcurrentLinkedQueue queue = new ConcurrentLinkedQueue<>(); } Process queued requests and submit successful bids to the database. package seckill; import org.apache.http.HttpRequest; public class Processor { public static void kill(BidInfo info) { DB.bids.add(info); } public static void process() { BidInfo info = new BidInfo(RequestQueue.queue.poll()); if (info != null) { kill(info); } } } class BidInfo { BidInfo(HttpRequest request) { /* Do something */ } } Database module uses an ArrayBlockingQueue to temporarily store potentially successful orders. package seckill; import java.util.concurrent.ArrayBlockingQueue; public class DB { public static int count = 10; public static ArrayBlockingQueue bids = new ArrayBlockingQueue<>(10); public static boolean checkReminds() { return true; } public static void bid() { BidInfo info = bids.poll(); while (count-- > 0) { // insert into Bids table info = bids.poll(); } } } 4.4 Database Design Discusses single‑instance vs. sharding vs. replication, routing strategies (range, hash, router service), and the need for redundancy to ensure availability. Highlights read‑heavy scenarios using caching layers (Redis/Memcached) to alleviate database load. Explains consistency challenges between cache and database and proposes double‑eviction and TTL strategies. 5. Challenges of Massive Concurrency Analyzes QPS calculations, the impact of increased response time on throughput, and the risk of system “snowball” failures. Emphasizes the importance of proper load‑balancing, connection limits, and over‑load protection at the CGI entry point. 6. Cheating Techniques and Countermeasures Describes attacks such as multiple requests per account, mass‑registered zombie accounts, and IP‑based request flooding, and suggests mitigations like per‑account request limiting, IP rate limiting with captchas, and behavior‑based account filtering. 7. Data Safety Under High Concurrency Explores thread‑safety issues, over‑selling problems, and solutions using pessimistic locks, FIFO queues, and optimistic locks (e.g., Redis WATCH) to ensure inventory consistency. 8. Summary High‑concurrency scenarios like flash‑sales share common challenges; applying consistent architectural principles—early request interception, caching, queueing, optimistic locking, and anti‑cheating measures—enables robust, scalable systems.