Flash Sale (Seckill) System Architecture, Technical Challenges and Solutions

1. Flash Sale Business Analysis

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

Flash‑sale characteristics: low price, massive promotion, instant sell‑out, scheduled launch, short duration with extremely high concurrency.

2. Flash Sale Technical Challenges

2.1 Impact on Existing Services

Running flash‑sale traffic together with normal services can overload the whole site; solution: isolate the flash‑sale system in a separate deployment or domain.

2.2 High Concurrency Load on Application and Database

Users continuously refresh the page before the sale starts, causing massive requests to the app server and database. Solution: serve a static page that does not hit the application layer.

2.3 Sudden Bandwidth Increase

A 200 KB product page for 10 000 concurrent users requires about 2 GB of bandwidth, far exceeding normal usage. Solution: purchase extra bandwidth and cache static pages on CDN.

2.4 Direct Order URL Exposure

To prevent users from accessing the order URL before the sale, generate the URL dynamically with a server‑side random token that becomes valid only at the start time.

2.5 Button Activation Timing

The purchase button is gray before the sale. Use a small JavaScript file that contains a flag; replace the file at sale start with a version that sets the flag to true and includes the order URL and token.

2.6 Allow Only the First Successful Order

Limit each server to a small number of order submissions; if the first order succeeds, disable the button for others via the JavaScript flag.

2.7 Pre‑order Checks

Each server checks the number of pending requests; if it exceeds a threshold, return a “sale ended” page. Also check the global submitted order count against inventory.

2.8 Timed Product Launch

Show the product before the sale but disable the purchase button; enforce timing checks on the backend to prevent pre‑sale edits.

2.9 Stock Deduction Strategies

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

2.10 Over‑selling Problem

Concurrent updates can cause sales to exceed inventory. Solution: use optimistic locking.

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

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

3. Flash Sale Architecture Principles

Intercept requests as early as possible; use a read‑heavy, write‑light pattern with heavy caching.

4. Flash Sale Architecture Design

4.1 Front‑End Layer

Display a countdown timer; static assets must be served from CDN to avoid bandwidth bottlenecks.

4.2 Site Layer

Limit request frequency per user ID or per product, returning cached pages for repeated requests within a short window.

4.3 Service Layer

Use a request queue (e.g., ConcurrentLinkedQueue) to buffer incoming requests, then process them sequentially. <code>package seckill; public class PreProcessor { private static boolean reminds = true; public static boolean checkReminds() { /* remote RPC check */ } public static void preProcess(HttpRequest request) { if (checkReminds()) { RequestQueue.queue.add(request); } else { forbidden(); } } }</code> Processing thread pulls from the queue and writes to the database. <code>package seckill; 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); } } </code> 4.4 Database Layer Use an ArrayBlockingQueue to hold potential successful orders, then persist them with a single‑threaded worker. <code>package seckill; public class DB { public static int count = 10; public static ArrayBlockingQueue<BidInfo> bids = new ArrayBlockingQueue<>(10); public static void bid() { BidInfo info = bids.poll(); while (count-- > 0) { // insert into DB info = bids.poll(); } } } </code> Database Design Considerations Discuss single‑node vs sharding, replication, read‑write separation, caching, and strategies for high availability and consistency (middleware, forced‑read‑master, cache double‑eviction, etc.). 5. Concurrency Challenges High QPS can quickly exhaust server connections; proper sizing of thread pools, using in‑memory stores like Redis, and avoiding heavy synchronous DB calls are essential. 6. Cheating and Defense Attackers may send many requests per account, use zombie accounts, or rotate IPs. Defenses include per‑account request limiting via Redis, IP‑rate limiting with captchas, and business‑level thresholds (account level, activity score). 7. Data Safety Under High Concurrency Over‑selling occurs when multiple requests read the same remaining stock. Solutions range from pessimistic locking (inefficient under high load) to FIFO queues (memory pressure) to optimistic locking with version checks, which is the preferred method. <code>update auction_auctions set quantity = quantity-1 where auction_id = ? and version = ?</code> 8. Summary Flash‑sale systems are extreme high‑concurrency scenarios that require isolation, static front‑end delivery, request throttling, queue‑based processing, optimistic locking, and robust caching to achieve both performance and correctness.