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

1. Flash‑sale business analysis – A normal e‑commerce flow includes product query, order creation, inventory deduction, order update, payment, and shipping. Flash‑sale (seckill) adds low price, massive promotion, instant sell‑out, scheduled launch, short duration, and extremely high concurrent requests.

2. Technical challenges

Impact on existing services: a flash‑sale can overwhelm the whole site; solution – deploy the seckill system independently, possibly under a separate domain.

High‑concurrency load on application and database: users constantly refresh the page, causing massive requests to app servers and DB; solution – static‑ize the product page and serve it without hitting the application layer.

Sudden bandwidth increase: a 200 KB page accessed by 10 000 users needs ~2 GB bandwidth; solution – purchase extra bandwidth and cache the page on CDN.

Direct order URL exposure: prevent users from accessing the order URL before the sale starts by adding a server‑generated random token to the URL.

Button activation control: the purchase button is gray until the sale starts; solution – use a JavaScript file that toggles a flag and includes the dynamic order URL, with versioned URLs to avoid CDN caching.

Only the first submitted order should reach the order subsystem; solution – limit the number of concurrent order requests per server and use load‑balancing algorithms.

Pre‑order checks: limit per‑server processed orders to 10, reject excess requests, and verify global order count against inventory.

3. Architecture principles – Intercept requests as early as possible, adopt a read‑most‑write‑few pattern, and heavily use caching to reduce backend pressure.

4. Architecture design

Front‑end layer : static HTML page with a countdown timer, served via CDN; use JavaScript to fetch server time for synchronization.

Site layer : rate‑limit per UID or per item within a short time window, returning the same cached page for repeated requests.

Service layer : queue incoming requests, process them sequentially, and forward successful ones to the order subsystem.

5. Concurrency queue selection

Java provides three common queue implementations; for a system where enqueue operations far exceed dequeue operations, ConcurrentLinkedQueue is preferred.

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

6. Database design

Single‑database concept, then sharding (horizontal partitioning) to handle large data volumes.

Sharding routing methods: range, hash, or a routing service.

Grouping (master‑slave replication) for high availability.

High‑availability strategies: dual‑master with a shadow‑master, middleware for read‑after‑write consistency, or forced reads from the master.

Cache integration: write‑through cache invalidation, double‑eviction, and TTL settings to keep cache and DB consistent.

7. Rapid scaling – Expand from 2 to 4 shards by changing the modulo configuration (MOD4) without data migration; promote one shard to master, add a new shadow‑master, and clean up excess data.

8. High‑concurrency challenges – Design fast backend interfaces, keep response time low (e.g., using Redis for in‑memory operations), calculate QPS limits, and implement overload protection to avoid avalanche failures.

9. Anti‑cheat measures

Limit one request per account at the entry point, using Redis flags with optimistic‑lock semantics.

Detect and throttle high‑frequency IPs, optionally presenting CAPTCHAs or blocking the IP.

Handle IP‑rotation attacks by raising participation thresholds or using behavioral data mining.

10. Data safety under high load

Prevent over‑selling by using pessimistic locks, FIFO queues, or optimistic locks (e.g., Redis WATCH).

FIFO queues avoid starvation but may exhaust memory under extreme load.

Optimistic locking with version numbers offers a balanced solution.

11. Summary – Flash‑sale and抢购 are typical high‑concurrency scenarios; despite varied concrete solutions, the challenges are similar, and the presented architectural ideas, scaling techniques, protection mechanisms, and consistency strategies provide a solid foundation for building reliable backend systems.