Design and Technical Solutions for a High‑Concurrency Flash Sale System

Flash‑sale (秒杀) systems like those on JD.com or Taobao attract huge traffic in a very short time, making backend design critical to avoid overselling and service collapse. The article first lists the main problems to address: overselling, high concurrency, interface abuse, predictable URLs, database coupling, and massive request handling.

Key Design and Technical Solutions

Database Design : Use a dedicated flash‑sale database with two core tables— miaosha_order and miaosha_goods —plus auxiliary product and user tables to isolate high‑traffic operations from the main business database.

Dynamic URL : Hide the sale endpoint by generating an MD5‑hashed random string as the URL; the frontend obtains the URL from the backend, which validates it before allowing the purchase.

Page Staticization : Render product details, images, and reviews into a static HTML page (e.g., via FreeMarker) so that user requests bypass the application server and database, greatly reducing load.

Redis Cluster : Deploy Redis in Sentinel mode as a cluster to handle the read‑heavy, write‑light flash‑sale workload and to prevent cache‑penetration during spikes.

Nginx Front‑End : Use Nginx as a high‑performance reverse proxy to distribute traffic among multiple Tomcat instances, achieving tens of thousands of concurrent connections.

SQL Optimization : Replace the classic “select‑then‑update” pattern with a single

UPDATE miaosha_goods SET stock = stock - 1 WHERE goods_id = #{goods_id} AND version = #{version} AND stock > 0

statement, employing optimistic locking to avoid overselling.

Redis Pre‑Decrement : Pre‑decrease stock in Redis before hitting the database; use Lua scripts for atomicity and restore stock on order cancellation.

Interface Rate Limiting :

Front‑end button disabling for a few seconds after click.

Reject repeated requests from the same user within a configurable window (e.g., 10 seconds) using Redis key expiration.

Token‑bucket algorithm via Guava RateLimiter to control request flow.

Example code for a simple token bucket:

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 + " waited " + waitTime);
        }
        System.out.println("Done");
    }
}

Improved version with timeout handling:

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; // seconds
            boolean valid = rateLimiter.tryAcquire(timeout, TimeUnit.SECONDS);
            if (!valid) continue; // drop request
            System.out.println("Task " + i + " executed");
        }
        System.out.println("End");
    }
}

Asynchronous Order Processing : After passing rate limiting and stock checks, push the order request into a message queue (e.g., RabbitMQ) for asynchronous handling, which decouples the front‑end burst from the database write path.

Service Degradation : Use circuit‑breaker tools such as Hystrix to provide fallback responses when a service instance fails, ensuring a graceful user experience.

Summary

The presented architecture can sustain hundreds of thousands of concurrent requests; for tens of millions, further scaling (sharding, Kafka, larger Redis clusters) would be required. The design demonstrates how to tackle high‑concurrency challenges through careful database isolation, caching, rate limiting, and asynchronous processing.