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

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: low price, massive promotion, instant sell‑out, scheduled launch, short duration, and extremely high concurrent requests.

2. Flash‑Sale Technical Challenges

Assuming a single product attracts 10,000 users, the system must address several issues:

Impact on existing services – co‑hosting flash‑sale with the main site can cause a full outage; solution: isolate the flash‑sale service, optionally using a separate domain.

High‑concurrency load on application and database – frequent page refreshes generate massive traffic; solution: static‑page the flash‑sale product page so requests bypass the application server.

Sudden bandwidth increase – a 200 KB page for 10,000 concurrent users needs ~2 GB/s; solution: lease extra bandwidth and cache the page in CDN.

Direct order URL exposure – users could bypass the start time; solution: generate a server‑side random token in the order URL, only valid after the sale begins.

Button activation control – the purchase button must stay disabled until the sale starts; solution: include a small JavaScript file that flips a flag at the start, with cache‑busting version query strings.

Only the first successful order should be processed – limit each server to a small number of concurrent order attempts and use cookies or a least‑connection load‑balancer to reduce duplicate attempts.

Pre‑order checks – each order server checks its local request count and the global submitted order count, rejecting excess requests.

Scheduled product launch – hide the “Buy Now” button until a predefined time, enforce server‑side clock sync.

Inventory reduction strategies – choose between "decrease on purchase" or "decrease on payment"; the article prefers the former for better user experience.

Oversell prevention – use optimistic locking; example SQL update:

update auction_auctions set quantity = #inQuantity# where auction_id = #itemId# and quantity = #dbQuantity#

Alternative "try‑decrement" approach:

update auction_auctions set quantity = quantity-#count# where auction_id = #itemId# and quantity >= #count#

Anti‑bot verification – employ a special verification code displayed on TV during the sale.

3. Flash‑Sale Architecture Principles

Intercept requests as early as possible (upstream).

Read‑heavy, write‑light workloads benefit from extensive caching.

4. Flash‑Sale Architecture Design

4.1 Frontend Layer Design

Display a product page with a countdown timer; static resources (HTML, CSS, JS, images) are served from CDN to avoid bandwidth bottlenecks.

Client‑side countdown uses local time; server‑side time sync API ensures consistency.

4.2 Site Layer Design

Limit request frequency per user ID and per item, caching identical requests for a short window.

4.3 Service Layer Design

Use a request queue to filter out unnecessary traffic; only forward valid requests to the database.

package seckill;
import org.apache.http.HttpRequest;
/**
 * Pre‑process stage: discard unnecessary requests, queue needed ones.
 */
public class PreProcessor {
    private static boolean reminds = true;
    public 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();
        }
    }
}

Choose ConcurrentLinkedQueue for the request queue because enqueue operations are lock‑free and fast.

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

Processor sends successful bids to the database queue:

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 hold potential successful bids and performs a simple loop to insert them while stock remains:

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 Bids table
            info = bids.poll();
        }
    }
}

4.4 Database Design

4.4.1 Basic Concepts

Single‑database (single‑shard) vs. sharding vs. grouping (master‑slave replication). Sharding distributes data horizontally; grouping adds redundancy for availability.

4.4.2 Design Ideas

Key concerns: data availability, read performance, consistency, scalability.

Redundancy (master‑master, shadow‑master) for high availability.

Read‑heavy workloads use read‑only replicas or cache layers (Redis, Memcached).

Write‑high availability via dual‑master with one acting as shadow‑master.

Cache‑aside pattern with double‑eviction to avoid stale data.

cache evict → write DB → after sync delay, evict cache again

Fast horizontal scaling by changing modulo routing (e.g., MOD2 → MOD4) without data migration.

5. Challenges of Massive Concurrency

5.1 Reasonable API Design

Separate static HTML (served by CDN) from high‑throughput backend APIs; keep API latency low, preferably in‑memory (Redis) and asynchronous.

5.2 Need for Speed

QPS = (servers × max‑connections) / avg‑response‑time. Under load, response time grows, reducing effective QPS and causing request back‑log and “snow‑avalanche” failures.

5.3 Restart and Overload Protection

When overload is detected, reject traffic at the entry point before restarting services; pre‑heat caches (Redis, Memcached) after restart.

6. Cheating Methods: Attack and Defense

6.1 Multiple Requests from One Account

Limit each account to a single concurrent request using Redis flags with WATCH/optimistic lock.

6.2 Multiple Accounts, High Request Rate

Detect high request frequency per IP and either present a CAPTCHA or block the IP.

6.3 Distributed Botnets (IP Rotation)

Hard to distinguish from legitimate traffic; mitigate by raising participation thresholds (account level, behavior analysis).

7. Data Safety under High Concurrency

7.1 Over‑selling Causes

Concurrent reads see stale inventory and all succeed, leading to oversell.

7.2 Pessimistic Lock

Locks serialize updates but increase latency and can cause request starvation.

7.3 FIFO Queue

Queueing requests avoids starvation but can exhaust memory under burst traffic.

7.4 Optimistic Lock

Version‑based updates (e.g., Redis WATCH) allow high concurrency with minimal blocking; failed version checks result in order rejection.

8. Summary

Flash‑sale and other high‑concurrency scenarios share common challenges: traffic spikes, resource contention, cheating, and data consistency. By isolating services, leveraging caching, applying queueing, and using optimistic locking, a robust, scalable system can be built to handle tens of thousands of simultaneous purchase attempts.