Flash Sale (Seckill) System Design and Technical Challenges

1. Flash‑sale business analysis

Normal e‑commerce flow includes product query, order creation, inventory deduction, order update, payment, and seller shipment. Flash‑sale characteristics are low price, massive promotion, instantaneous sell‑out, scheduled listing, and very short, high‑concurrency bursts.

2. Technical challenges

When a single product attracts 10,000 concurrent users, the system faces several issues:

Impact on existing services – solution: isolate the flash‑sale system with a separate deployment or domain.

High read/write load on application servers and databases – solution: static‑ize product pages and bypass the application layer.

Sudden bandwidth surge (e.g., 200 KB page × 10 000 requests = 2 GB) – solution: lease additional bandwidth and cache pages on CDN.

Direct order URL exposure – solution: generate dynamic URLs with server‑side random tokens.

Button activation timing – solution: control via a small JavaScript file that toggles a flag and includes the order URL with a random token.

Only the first successful order should be processed – solution: limit per‑server request count and use cookies or least‑connection load balancing.

Pre‑order checks – solution: check per‑server processed request count and global submitted order count before forwarding to the order subsystem.

3. Architecture principles

1) Intercept requests as early as possible; 2) Use caching for read‑heavy scenarios (99.9% reads, 0.1% writes).

4. Architecture design

4.1 Front‑end layer

Display a static flash‑sale page with a countdown; static resources are served from CDN to avoid bandwidth bottlenecks. Time synchronization between client and server is handled via a lightweight JSON endpoint.

4.2 Site layer

Limit per‑user and per‑item request frequency, returning the same cached page for repeated requests within a short window.

4.3 Service layer

Use a request queue to filter unnecessary traffic and only forward valid requests to the database. Example pre‑processor code:

package seckill;<br/>import org.apache.http.HttpRequest;<br/>/**<br/> * Pre‑process stage: reject unnecessary requests, queue valid ones.<br/> */<br/>public class PreProcessor {<br/>    private static boolean reminds = true;<br/>    private static void forbidden() { /* Do something. */ }<br/>    public static boolean checkReminds() {<br/>        if (reminds) {<br/>            if (!RPC.checkReminds()) { reminds = false; }<br/>        }<br/>        return reminds;<br/>    }<br/>    public static void preProcess(HttpRequest request) {<br/>        if (checkReminds()) { RequestQueue.queue.add(request); } else { forbidden(); }<br/>    }<br/>}

Concurrent queue implementation:

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

Processor that moves requests to the DB:

package seckill;<br/>import org.apache.http.HttpRequest;<br/>public class Processor {<br/>    public static void kill(BidInfo info) { DB.bids.add(info); }<br/>    public static void process() {<br/>        BidInfo info = new BidInfo(RequestQueue.queue.poll());<br/>        if (info != null) { kill(info); }<br/>    }<br/>}<br/>class BidInfo {<br/>    BidInfo(HttpRequest request) { /* Do something. */ }<br/>}

Database module using an ArrayBlockingQueue:

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

4.4 Database design

Discusses single‑database, sharding, and grouping concepts, routing strategies (range, hash, router service), and redundancy for high availability. Illustrates read‑write separation, cache‑first reads, and strategies to avoid stale data, such as double‑delete after write.

5. High‑concurrency challenges

Explains QPS calculations, the impact of increased response time on throughput, and the risk of overload leading to “snowball” failures. Emphasizes the need for overload protection at the entry layer.

6. Cheating and defense

Describes attacks such as multiple requests from a single account, zombie‑account farms, IP‑rotation bots, and proposes mitigations: per‑account request limiting via Redis flags, CAPTCHA or IP blocking, behavior‑based account scoring, and higher participation thresholds.

7. Data safety under high load

Analyzes overselling caused by race conditions, compares pessimistic locking (high latency) with FIFO queuing (memory pressure) and recommends optimistic locking with version checks (e.g., Redis WATCH) to ensure atomic inventory updates.

8. Summary

Flash‑sale systems exemplify high‑concurrency challenges; a layered architecture that isolates traffic, leverages caching, uses lightweight queuing, applies optimistic locking, and incorporates anti‑cheating mechanisms can achieve the required scalability, reliability, and data consistency.