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

Business Analysis – A typical e‑commerce flow is extended by seckill features that involve low price, massive promotion, short‑time limited inventory, and extremely high concurrent requests, often reaching tens of thousands of users simultaneously.

Technical Challenges – The surge can impact existing services, overload application and database servers, exhaust network bandwidth, expose direct order URLs, and cause inventory oversell. Solutions include isolating the seckill system, static page caching, CDN distribution, dynamic URL generation, JavaScript‑controlled button activation, and limiting order submissions.

Architecture Principles – Intercept requests upstream, use read‑heavy/write‑light patterns with caching, and keep the seckill service lightweight.

Layered Design

• Frontend Layer – Static product page with countdown, CDN‑hosted assets, and JavaScript that toggles the purchase button at the start time.

• Site Layer – Rate‑limit per user ID and per item, cache responses for a short interval.

• Service Layer – Distribute requests via Nginx/Apache, pre‑process to reject out‑of‑stock requests, and forward valid requests to a transaction queue.

Modules and Code

Request pre‑processor example:

package seckill;

import org.apache.http.HttpRequest;

public class PreProcessor {

private static boolean reminds = true;

public static boolean checkReminds() {

// remote check

if (!RPC.checkReminds()) { reminds = false; }

return reminds;

}

public static void preProcess(HttpRequest request) {

if (checkReminds()) { RequestQueue.queue.add(request); }

else { forbidden(); }

}

}

Concurrent queue selection – ConcurrentLinkedQueue is preferred for high enqueue rate with occasional lock on dequeue.

Request queue definition:

public class RequestQueue {

public static ConcurrentLinkedQueue<HttpRequest> queue = new ConcurrentLinkedQueue<>();

}

Processor that sends bids to the database:

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); }

}

}

Database module using an ArrayBlockingQueue to hold potential successful bids and a simple optimistic‑lock update:

public class DB {

public static int count = 10;

public static ArrayBlockingQueue<BidInfo> bids = new ArrayBlockingQueue<>(10);

public static boolean checkReminds() { return true; }

public static void bid() {

BidInfo info = bids.poll();

while (count-- > 0) { /* insert bid */ }

}

}

Database Design – Discusses single‑instance vs. sharding vs. grouping, replication strategies, read‑write separation, and cache invalidation techniques to maintain consistency.

High‑Concurrency Handling – Emphasises QPS calculations, the need for fast in‑memory stores (Redis), load‑balancing, and overload protection such as request rejection at the entry point.

Cheating Prevention – Limits per‑account requests, IP‑rate limiting, captcha challenges, and behavior‑based account filtering.

Data Safety – Covers oversell problems, pessimistic vs. optimistic locking, FIFO queues, and the use of Redis WATCH for versioned updates.

Conclusion – Flash‑sale systems share common high‑concurrency challenges; applying layered isolation, caching, queueing, and proper locking yields a robust, scalable solution.