Flash Sale (秒杀) System Architecture, Technical Challenges and Solutions

1. Flash‑sale (秒杀) business analysis describes the normal e‑commerce steps (query product, create order, deduct inventory, update order, payment, seller shipment) and highlights flash‑sale traits: low price, massive promotion, instant sell‑out, scheduled launch, short duration and extremely high concurrent requests.

2. Technical challenges include impact on existing services, massive read/write load, bandwidth spikes (e.g., 200 KB page × 10 000 requests ≈ 2 GB/s), direct order URL exposure, button activation timing, ensuring only the first order reaches the order subsystem, pre‑order checks, timed product launch, inventory reduction strategies (snapshot vs. payment), and overselling caused by concurrent inventory updates.

3. Architecture principles: intercept requests as early as possible, treat the workload as read‑most‑write‑few and heavily use caching, and isolate the flash‑sale system from the main site.

4. Architecture design:

Frontend layer: static product page cached on CDN, countdown timer implemented in JavaScript, button state controlled by a small JS file that toggles a flag when the sale starts.

Site layer: limit per‑user and per‑item request frequency, cache identical responses for a short window.

Service layer: pre‑process requests, reject when inventory is exhausted, and queue valid requests for later processing.

Database layer: use sharding, replication (single‑master, shadow‑master), and cache to achieve high read performance.

Key Java components are shown below.

package seckill;
import org.apache.http.HttpRequest;
/**
 * 预处理阶段，把不必要的请求直接驳回，必要的请求添加到队列中进入下一阶段.
 */
public class PreProcessor {
    private static boolean reminds = true;
    private static void forbidden() {
        // Do something.
    }
    public static boolean checkReminds() {
        if (reminds) {
            // Remote check via RPC.
            if (!RPC.checkReminds()) {
                reminds = false;
            }
        }
        return reminds;
    }
    public static void preProcess(HttpRequest request) {
        if (checkReminds()) {
            RequestQueue.queue.add(request);
        } else {
            forbidden();
        }
    }
}

package seckill;
import java.util.concurrent.ConcurrentLinkedQueue;
import org.apache.http.HttpRequest;
public class RequestQueue {
    public static ConcurrentLinkedQueue<HttpRequest> queue = new ConcurrentLinkedQueue<HttpRequest>();
}

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.
    }
}

package seckill;
import java.util.concurrent.ArrayBlockingQueue;
public class DB {
    public static int count = 10;
    public static ArrayBlockingQueue<BidInfo> bids = new ArrayBlockingQueue<BidInfo>(10);
    public static boolean checkReminds() {
        // TODO
        return true;
    }
    public static void bid() {
        BidInfo info = bids.poll();
        while (count-- > 0) {
            // insert into Bids ...
            info = bids.poll();
        }
    }
}

5. High‑concurrency challenges focus on QPS calculation, overload, snowball effect, and the need for fast in‑memory operations (e.g., Redis) and proper overload protection at the entry point.

6. Anti‑cheat measures cover limiting a single account to one request, IP‑rate limiting with captchas or bans, handling zombie accounts by detecting abnormal IP or account patterns, and raising participation thresholds.

7. Data safety discusses overselling causes, pessimistic locking drawbacks, FIFO queue memory pressure, and recommends optimistic locking (e.g., Redis WATCH) with version checks to ensure atomic inventory deduction.

8. The conclusion reiterates that flash‑sale scenarios are representative high‑concurrency problems and that systematic architectural design—combining request interception, caching, queuing, sharding, replication, and consistency controls—provides a reliable solution.