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

Flash sale (秒杀) requires handling massive concurrent requests; the article first outlines the typical e‑commerce flow and the special characteristics of flash sales such as low price, short duration, and timed release.

Technical challenges include impact on existing services, high read/write load on application and database servers, sudden bandwidth spikes, premature order URL exposure, button activation timing, and limiting order submissions to the first successful buyer.

Solutions propose isolating the flash‑sale system with a separate domain, static page caching, CDN distribution, JavaScript‑controlled button activation, dynamic order URLs with server‑generated random tokens, request throttling at product and user levels, and restricting order processing to a small number of servers.

Architecture principles emphasize intercepting requests upstream, using read‑heavy caching for the typical 99.9% read‑only workload, and simplifying page design to reduce server load.

Design details cover front‑end page with countdown timers, CDN‑hosted static resources, server‑side time synchronization, browser‑side request limiting, site‑level rate limiting per user or item, service‑layer request queuing, and a database layer that employs optimistic locking or queue‑based processing.

Code examples illustrate pre‑processing checks and request queuing using ConcurrentLinkedQueue and optimistic‑lock SQL updates:

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

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

package seckill;
import org.apache.http.HttpRequest;
public class PreProcessor {
    private static boolean reminds = true;
    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 {
            // reject request
        }
    }
}

Database design discusses single‑instance, sharding, and grouping strategies, read/write high availability, caching layers, and methods to avoid over‑selling such as optimistic locking and cache double‑eviction.

High‑concurrency challenges like QPS limits, response‑time growth, overload protection, and snowball effects are analyzed, with recommendations for load balancing, capacity planning, and graceful degradation.

Anti‑cheat measures address single‑account flood, zombie‑account farms, and IP rotation, suggesting captchas, IP throttling, and behavior‑based filtering to protect fairness.

The article concludes that flash‑sale systems share common challenges and solutions across high‑traffic scenarios, emphasizing careful design of concurrency control, caching, and fault tolerance.