Design and Technical Challenges of High‑Concurrency Flash Sale (Seckill) Systems

The document begins by contrasting a normal e‑commerce flow—search, order creation, inventory deduction, payment, shipping—with the unique traits of flash‑sale (seckill) events such as low price, massive promotion, instantaneous sell‑out, scheduled launch, and extremely short, high‑concurrency bursts.

Technical challenges are identified: the seckill traffic can cripple the existing site, overload application and database servers, saturate network bandwidth, expose direct order URLs, and require precise control of the purchase button state. Solutions include deploying the seckill system independently (even on a separate domain), serving static product pages via CDN, and using JavaScript to toggle button activation only at the start time.

Key architectural principles are presented: intercept requests as early as possible, treat the workload as read‑many/write‑few and heavily cache data, and keep the seckill service lightweight. The front‑end design uses a static page with a countdown, a versioned JavaScript file that flips a flag and injects the order URL, and client‑side rate limiting.

At the service layer, incoming requests are pre‑processed to reject excess submissions, placed into a concurrent queue, and processed by worker threads that forward successful bids to the database. Sample Java code illustrates the pre‑processor, request queue, and processor components:

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) {
            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. */ }
    }
}

The database module uses an ArrayBlockingQueue to temporarily hold potential successful bids and applies optimistic locking (e.g., SQL

UPDATE auction_auctions SET quantity = #inQuantity# WHERE auction_id = #itemId# AND quantity = #dbQuantity#

) to prevent overselling.

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() { return true; }
    public static void bid() {
        BidInfo info = bids.poll();
        while (count-- > 0) {
            // insert into table Bids ...
            // select count(id) from Bids where item_id = ?
            info = bids.poll();
        }
    }
}

Database design considerations cover sharding, replication (grouping), and consistency strategies such as middleware routing, forced reads from the master, and cache‑double‑eviction to mitigate stale data. The article also discusses scaling read performance via indexing, adding read replicas, or employing cache layers.

High‑concurrency operational issues are examined, including QPS calculations, overload‑induced latency spikes, snowball effects, and the need for overload protection at the entry point. Anti‑cheat mechanisms like per‑account request limiting, captcha challenges, IP rate‑limiting, and behavior‑based filtering are recommended.

Data safety under massive parallelism is addressed through pessimistic locking, FIFO queues, and optimistic locking with version checks (e.g., Redis WATCH). The article concludes that while flash‑sale systems vary in implementation, they share common challenges that can be tackled with consistent architectural patterns.