How to Build a Robust High‑Concurrency Flash Sale System

Problems to Consider in a Flash Sale System

Flash‑sale (秒杀) scenarios, like those on JD or Taobao, face critical issues such as overselling, high concurrency, request scraping, URL exposure, database overload, and massive request spikes.

Overselling

When inventory is limited (e.g., 100 items) but orders exceed supply (e.g., 200), the low‑price nature of flash sales can cause severe financial loss, making overselling the top concern.

High Concurrency

Flash sales last only a few minutes and attract a flood of users, leading to a surge of requests that can overwhelm caches and databases.

Interface Scraping

Automated tools can repeatedly hit the backend API hundreds of times per second; preventing these invalid requests is essential.

Flash‑sale URL Exposure

Users may discover the underlying API URL via browser dev tools and trigger purchases directly; dynamic URL generation is needed to hide the endpoint until the sale starts.

Database Design

Running flash‑sale traffic on the same database as other services risks cascading failures; a dedicated flash‑sale database isolates the impact.

Massive Request Volume

Even with caching, a single Redis instance (≈40 k QPS) may be insufficient for the tens or hundreds of thousands of requests a flash sale generates, leading to cache breakdown and DB overload.

Design and Technical Solutions

Flash‑sale Database Schema

Use a separate database with at least two tables: miaosha_order (order records) and miaosha_goods (product stock). Additional tables for product details and user information are recommended.

Dynamic Flash‑sale URL

Generate the sale URL by encrypting a random string with MD5; the front end first requests the actual URL from the backend, which validates the request before allowing the sale.

Static Page Rendering

Render product details, parameters, transaction history, images, and reviews into a static HTML page using a template engine (e.g., FreeMarker) to avoid backend and DB hits during the sale.

Redis Cluster

Deploy Redis in a Sentinel‑based cluster to improve performance and availability for the high‑read, low‑write flash‑sale workload.

Use Nginx

Place Nginx in front of Tomcat; Nginx can handle tens of thousands of concurrent connections and forward traffic to a Tomcat cluster, greatly boosting concurrency.

Simplify SQL

Combine stock check and decrement into a single UPDATE statement with optimistic locking:

update miaosha_goods set stock = stock - 1 where goods_id = #{goods_id} and version = #{version} and stock > 0;

This prevents overselling and reduces SQL count.

Redis Pre‑decrement Stock

Before the sale, set the stock in Redis (e.g., redis.set(goodsId, 100)). Each order atomically decrements the Redis key; if the stock falls below zero, the request is rejected. Use Lua scripts for atomicity and restore stock on order cancellation.

Rate‑Limiting Strategies

Front‑end Limiting : Disable the purchase button for a few seconds after a click. Same‑User Re‑request Blocking : Reject repeated requests from the same user within a configurable interval (e.g., 10 s) using Redis key expiration. Token‑Bucket Algorithm : Employ Guava’s RateLimiter to issue tokens at a fixed rate. Example code: <code>public class TestRateLimiter { public static void main(String[] args) { // 1 token per second final RateLimiter rateLimiter = RateLimiter.create(1); for (int i = 0; i < 10; i++) { double waitTime = rateLimiter.acquire(); System.out.println("Task " + i + " wait time " + waitTime); } System.out.println("Done"); } } </code> A second example shows non‑blocking acquisition with a timeout: <code>public class TestRateLimiter2 { public static void main(String[] args) { final RateLimiter rateLimiter = RateLimiter.create(1); for (int i = 0; i < 10; i++) { long timeout = 0L; // 0.5 seconds expressed as long for illustration boolean isValid = rateLimiter.tryAcquire(0.5, TimeUnit.SECONDS); System.out.println("Task " + i + " valid: " + isValid); if (!isValid) continue; System.out.println("Task " + i + " executing"); } System.out.println("Finished"); } } </code> Asynchronous Order Processing After rate limiting and stock verification, push order requests to a message queue (e.g., RabbitMQ) for asynchronous handling, decoupling the order service and improving resilience. Successful orders can trigger SMS notifications; failures can be retried via compensation mechanisms. Service Degradation If a server crashes during the sale, fallback services (e.g., using Hystrix) should provide graceful error messages instead of hard failures. Summary The following flowchart (illustrated by the image below) outlines the end‑to‑end flash‑sale process, capable of handling hundreds of thousands of concurrent requests. For traffic in the tens of millions, further scaling—such as database sharding, Kafka queues, and larger Redis clusters—would be required.