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

Flash‑sale (秒杀) systems, like those used by JD or Taobao, must handle extremely short sale windows and massive request spikes while preventing overselling and abuse.

Key problems to consider:

Overselling when inventory is limited.

High concurrency that can overwhelm caches and databases.

Interface scraping by bots and repeated invalid requests.

Predictable sale URLs that can be discovered and abused.

Database coupling that risks affecting other services.

Enormous request volume that exceeds single‑node Redis capacity.

Design and technical solutions:

Separate flash‑sale database with order and product tables, plus auxiliary goods and user tables.

Dynamic, MD5‑hashed sale URLs generated at runtime to hide endpoints.

Static page generation (e.g., using FreeMarker) to offload read traffic from the backend.

Redis cluster (sentinel mode) for high‑availability caching and pre‑decrement of stock:

redis.set(goodsId,100)

Integer stock = (Integer)redis.get(goodsId)

Front‑end rate limiting (disable button for a few seconds) and back‑end token‑bucket algorithm using Guava RateLimiter.

public class TestRateLimiter {
    public static void main(String[] args) {
        final RateLimiter rateLimiter = RateLimiter.create(1);
        for (int i = 0; i < 10; i++) {
            double waitTime = rateLimiter.acquire();
            System.out.println("Task " + i + " wait " + waitTime);
        }
        System.out.println("Done");
    }
}

Improved SQL for stock deduction using optimistic locking:

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

Redis‑based request deduplication with key expiration to reject repeated user requests within a configurable interval.

Asynchronous order processing via message queues (e.g., RabbitMQ) to achieve decoupling, peak‑shaving, and reliability.

Service degradation and fallback (e.g., Hystrix circuit breaker) to provide graceful user messages when components fail.

The accompanying flow diagram demonstrates how these components interact to support tens of thousands of concurrent requests; larger scales would require further sharding, Kafka queues, and additional Redis clusters.

Overall, the article provides a practical blueprint for building a robust, high‑throughput flash‑sale backend.