Flash Sale (Seckill) System Analysis, Technical Challenges, Architecture Design, and High‑Concurrency Solutions

1. Flash‑Sale Business Analysis

Typical e‑commerce flow: query product → create order → deduct inventory → update order → payment → seller ships.

Flash‑sale traits: low price, massive promotion, instant sell‑out, scheduled launch, short duration, and extremely high concurrent requests.

2. Flash‑Sale Technical Challenges

2.1 Impact on Existing Services

Running flash‑sale alongside normal services can overload the whole site; solution: isolate the flash‑sale system on a separate domain or server.

2.2 High‑Concurrency Load on Application and Database

Continuous page refresh before the sale creates massive traffic to the app and DB; solution: static‑ize the product page so requests bypass the application layer.

2.3 Sudden Network and Bandwidth Surge

Assuming a 200 KB page for 10 000 users, 2 GB bandwidth is required; solution: lease extra bandwidth from ISPs and cache static pages on CDN.

2.4 Direct Order URL Exposure

If the order URL is known before the sale, users can bypass the timer; solution: generate a dynamic URL with a server‑side random token available only at sale start.

2.5 Button Activation Control

The purchase button should be disabled until the sale starts; solution: use a small JavaScript file that flips a flag and includes the order URL with a random token, refreshed with a version query string to avoid CDN caching.

2.6 Allow Only the First Successful Order

Limit each server to a small number of order requests and use cookie‑based routing or least‑connection load balancing to reduce duplicate attempts.

2.7 Pre‑order Checks

Servers check local request counts and global order counts; if limits are exceeded, they return a “sale ended” page.

2.8 Timed Product Listing

Display the product before the sale but keep the purchase button disabled; enforce server‑side time checks to prevent URL manipulation.

2.9 Inventory Deduction Strategies

Two approaches: deduct inventory on order placement or on payment; the former offers better user experience.

2.10 Over‑selling Issue

Concurrent inventory updates can cause sales exceeding stock; solution: use optimistic locking.

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

Or attempt‑deduction: <code>update auction_auctions set quantity = quantity-#count# where auction_id = #itemId# and quantity >= #count#</code>

3. Flash‑Sale Architecture Principles

3.1 Intercept Requests Upstream

Traditional flash‑sale systems fail because backend data layers become bottlenecks; intercepting traffic early reduces load.

3.2 Read‑Heavy, Write‑Light Use Caching

Flash‑sale is a classic read‑dominant scenario (99.9% reads, 0.1% writes), making caching essential.

4. Flash‑Sale Architecture Design

4.1 Front‑End Layer

Static product page with countdown timer; static assets must be served from CDN to avoid bandwidth bottlenecks. Client‑side timer may drift from server time; synchronize via a lightweight API returning server time.

4.2 Site Layer

Rate‑limit per user ID and per product, caching identical responses for a short window.

4.3 Service Layer

Queue incoming requests; only a limited number of write requests reach the database. Example pre‑processor code: <code>package seckill; import org.apache.http.HttpRequest; /** * 预处理阶段，把不必要的请求直接驳回，必要的请求添加到队列中进入下一阶段. */ public class PreProcessor { private static boolean reminds = true; private 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(); } } } </code> Request queue implementation using ConcurrentLinkedQueue: <code>package seckill; import java.util.concurrent.ConcurrentLinkedQueue; import org.apache.http.HttpRequest; public class RequestQueue { public static ConcurrentLinkedQueue<HttpRequest> queue = new ConcurrentLinkedQueue<>(); } </code> Processor that pushes bids to DB queue: <code>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 */ } } </code> Database module using ArrayBlockingQueue: <code>package seckill; import java.util.concurrent.ArrayBlockingQueue; 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 into Bids ... info = bids.poll(); } } } </code> 4.4 Database Design Discusses single‑node, sharding, grouping, and replication strategies to ensure availability, read performance, consistency, and scalability. Key concepts: single database, sharding (range, hash, router service), grouping (master‑slave replication), and multi‑level redundancy. Read‑heavy workloads are served by cache layers (Redis/Memcached) to avoid DB bottlenecks. 5. Challenges of Massive Concurrency 5.1 Reasonable API Design Backend APIs must be ultra‑fast, preferably operating on in‑memory stores; asynchronous writes are recommended. 5.2 Necessity of Speed QPS calculations illustrate how increased response time drastically reduces throughput, leading to request backlogs and potential system “snowball” failures. 5.3 Restart and Overload Protection During overload, reject traffic at the entry point before restarting services; use circuit‑breaker or rate‑limiting mechanisms. 6. Cheating Tactics and Defenses 6.1 Multiple Requests from One Account Limit each account to a single active request using Redis flags or a dedicated queue. 6.2 Multiple Accounts with Bulk Requests Detect high request rates per IP and enforce captchas or outright bans. 6.3 Distributed IP Bots When attackers rotate IPs, raise participation thresholds (e.g., account level) and employ behavioral data mining to filter zombie accounts. 7. Data Safety Under High Concurrency 7.1 Over‑selling Causes Concurrent reads of remaining stock can lead to multiple successful purchases. 7.2 Pessimistic Locking Locks serialize updates but degrade performance under massive load. 7.3 FIFO Queue Approach Queueing requests avoids starvation but can exhaust memory. 7.4 Optimistic Locking Use version numbers or Redis WATCH to allow concurrent attempts while ensuring only one succeeds, balancing safety and throughput. 8. Conclusion Flash‑sale and high‑concurrency scenarios share common challenges; applying layered request interception, caching, optimistic locking, and robust anti‑cheating measures yields a scalable, reliable system.