How to Build a Robust Flash Sale System: Architecture, Challenges, and Code Solutions

1. Issues to Consider in a Flash Sale System

Overselling: When inventory is limited (e.g., 100 items) but demand exceeds supply, the system must prevent selling more than available.

High concurrency: Flash sales attract massive traffic within minutes, risking cache breakdown and database overload.

Interface abuse: Automated tools can send hundreds of requests per second, so the system must filter invalid or repeated requests.

URL exposure: Users may discover the sale URL via browser tools and trigger purchases prematurely; the URL should be hidden or dynamically generated.

Database isolation: The flash‑sale workload should not interfere with other business services; a dedicated database is recommended.

Massive request volume: Even with caching, a single Redis instance may not handle hundreds of thousands of QPS; clustering is needed.

2. Design and Technical Solutions

2.1 Flash Sale Database Design

A separate database with at least two tables—one for flash‑sale orders and one for flash‑sale goods—isolates the high‑load traffic from the main system.

2.2 Dynamic Flash Sale URL

Generate the sale URL using an MD5 hash of a random string so that even developers cannot know it before the sale starts; the frontend obtains the URL from the backend after validation.

2.3 Page Staticization

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

2.4 Redis Cluster

Use Redis in sentinel mode as a cluster to handle cache‑penetration and improve availability under extreme QPS.

2.5 Nginx Front‑End

Deploy Nginx as a high‑performance reverse proxy; it can handle tens of thousands of concurrent connections and forward traffic to a Tomcat cluster.

2.6 SQL Optimization

Combine stock check and decrement into a single UPDATE statement with optimistic locking to avoid overselling.

2.7 Redis Pre‑decrement

Set initial stock in Redis, decrement atomically on each order, and use Lua scripts for consistency; restore stock on order cancellation.

2.8 Interface Rate Limiting

Apply front‑end button disabling, per‑user request cooldown (e.g., 10 seconds via Redis key expiration), and a token‑bucket algorithm using Guava's RateLimiter.

public class TestRateLimiter {
    public static void main(String[] args) {
        // 1 second produces 1 token
        final RateLimiter rateLimiter = RateLimiter.create(1);
        for (int i = 0; i < 10; i++) {
            // This call blocks until a token is available
            double waitTime = rateLimiter.acquire();
            System.out.println("Task " + i + " wait time " + waitTime);
        }
        System.out.println("Done");
    }
}

A second example shows how to reject tasks that cannot acquire a token within a timeout.

public class TestRateLimiter2 {
    public static void main(String[] args) {
        final RateLimiter rateLimiter = RateLimiter.create(1);
        for (int i = 0; i < 10; i++) {
            long timeout = (long) 0.5;
            boolean isValid = rateLimiter.tryAcquire(timeout, TimeUnit.SECONDS);
            System.out.println("Task " + i + " valid: " + isValid);
            if (!isValid) continue;
            System.out.println("Task " + i + " executing");
        }
        System.out.println("End");
    }
}

2.9 Asynchronous Order Processing

Use a message queue (e.g., RabbitMQ) to decouple order creation from the front‑end, providing peak‑shaving, fault tolerance, and the ability to notify users of success or trigger compensation on failure.

2.10 Service Degradation

Implement fallback services with circuit‑breaker tools such as Hystrix to return friendly messages when a component fails.

3. System Architecture Diagram

4. Summary

The presented architecture can sustain hundreds of thousands of concurrent requests; for tens of millions, further scaling such as database sharding, Kafka queues, and larger Redis clusters would be required. The goal is to illustrate how to handle high concurrency, prevent overselling, and build a resilient flash‑sale service.