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

1. Flash‑sale Business Analysis

Normal e‑commerce process: query product, create order, deduct inventory, update order, pay, ship.

Flash‑sale characteristics: low price, heavy promotion, instant sell‑out, timed launch, short duration with extremely high concurrency.

2. Technical Challenges

Impact on existing services – a flash‑sale can overload the whole site and cause a complete outage.

High read/write pressure on application servers and databases when thousands of users refresh the page simultaneously.

Sudden bandwidth surge – a 200 KB page accessed by 10 000 users requires ~2 GB/s of network bandwidth.

Direct order URL exposure – users could bypass the timed start if they obtain the order URL early.

Button activation control – the purchase button must stay disabled until the sale starts, yet the page is cached on CDN.

Only the first successful order should be sent to the order subsystem.

Pre‑order validation – limit per‑server request count and global order count.

Timed product launch – prevent edits to the product during the sale window.

Inventory deduction strategies – "deduct on click" vs. "deduct on payment"; the article prefers the former.

Overselling risk – concurrent updates can cause sales to exceed stock.

Seckill‑specific verification codes to block bots.

Solution: isolate the flash‑sale system in a separate domain and deploy it independently.

3. Architecture Principles

Intercept requests as early as possible (upstream).

Read‑heavy, write‑light workload – heavily use caching.

Traditional flash‑sale systems fail because the backend data layer becomes a bottleneck; most requests time out while only a tiny fraction succeed.

4. Detailed Architecture Design

4.1 Front‑end Layer

Display a static product page with a countdown timer. Static resources (HTML, CSS, JS, images) are stored on CDN to avoid bandwidth bottlenecks.

Timer is driven by client‑side JavaScript synchronized with a lightweight server‑side time API.

4.2 Site Layer

Limit request frequency per user ID and per item, returning cached pages for repeated requests within a short window.

4.3 Service Layer

Use a request queue to throttle write operations. Only a limited number of write requests are allowed to reach the database; the rest are rejected early.

package seckill;
import org.apache.http.HttpRequest;
/**
 * Pre‑processing stage – reject unnecessary requests, queue necessary ones.
 */
public class PreProcessor {
    private static boolean reminds = true;
    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();
        }
    }
    private static void forbidden() { /* Do something */ }
}

The queue is implemented with a lock‑free ConcurrentLinkedQueue because enqueue operations dominate dequeue operations.

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

Processor pulls requests from the queue and forwards them 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 possibly 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‑database, sharding, and grouping (master‑slave replication). Highlights read‑heavy scenarios, use of cache, and strategies for high availability of reads and writes.

Replication models: dual‑master with one active master and one shadow‑master for failover; read‑through cache to reduce DB load; cache‑double‑eviction to avoid stale data.

4.5 High‑Concurrency Challenges

QPS calculations show that response time growth quickly reduces effective throughput, leading to bottlenecks and avalanche failures.

Overload protection should be placed at the entry layer (e.g., Nginx) to reject excess traffic before it reaches the application.

5. Cheating and Defense

Describes three cheat vectors: multiple requests from a single account, massive zombie‑account farms, and IP‑rotation bots. Provides countermeasures such as per‑account request limiting, captcha challenges, IP blocking, and behavior‑based risk scoring.

6. Data Safety Under High Load

Explains overselling caused by race conditions and compares pessimistic lock, FIFO queue, and optimistic lock approaches.

Optimistic locking (e.g., Redis WATCH ) is recommended for flash‑sale scenarios because it avoids long wait times while guaranteeing correctness.

7. Summary

Flash‑sale and other high‑concurrency scenarios share common challenges: massive request spikes, database contention, and cheating. By isolating the sale system, using lightweight in‑memory queues, caching, sharding, replication, and optimistic locking, a robust, scalable backend can be built to handle tens of thousands of requests per second while preserving data integrity.