Designing a High‑Performance Flash‑Sale System: Architecture & Best Practices

This article explains the architecture design of a flash‑sale (秒杀) system from seven different dimensions, focusing on high concurrency handling and reliability.

Nginx + front‑end/back‑end separation + CDN cache + gateway (rate limiting + circuit breaking)

Cluster routing layer + Redis (hot data cache, distributed lock)

MQ cluster

Business processing layer

Database layer (read/write separation, hot‑spot isolation)

1. Characteristics of Flash‑Sale Business

Massive simultaneous page refreshes

Massive concurrent purchase attempts

Potential malicious competition from automated tools

2. Overall Design Approach

2.1 Peak‑Limiting and Flow Control

Front‑end + Redis intercept: only requests that successfully decrement stock in Redis proceed downstream

MQ buffers orders, protecting downstream services; consumers fetch tasks based on their processing capacity

Introduce answer‑captcha, random request sleep, etc., to smooth traffic spikes

Security Protection

Front‑end validates activity start time and prevents duplicate clicks

IP/User‑ID rate limiting, captcha challenges, and blacklists to block malicious bots

Overload shedding: discard requests when QPS or CPU exceeds thresholds

Page Optimization (Static‑Dynamic Separation)

Keep flash‑sale page assets minimal (small images, lightweight JS/CSS)

Use asynchronous updates for purchase actions to avoid full page reloads

Configure Nginx for static‑dynamic separation, enable gzip compression, or use Varnish for in‑memory static caching

server {
        listen       8088;
        location ~ \.(gif|jpg|jpeg|png|bmp)$ {
                root    C:/Users/502764158/Desktop/test;
        }
        location ~ \.(jsp|do)$ {
                proxy_pass http://localhost:8082;
        }
}

Asynchronous Processing

After Redis successfully locks a purchase, push subsequent business logic to a thread pool for async handling

Thread pool tasks are placed onto MQ, allowing independent subsystems (order, inventory, payment, coupon) to process them

Accept reduced consistency for higher concurrency; monitor logs to detect and reconcile problematic orders

Hot‑Spot Isolation

Avoid flash‑sale load affecting normal services by separating traffic at the routing, MQ, and database layers, using middleware configurations where full isolation is too costly.

Cluster node separation via Nginx routing rules

MQ separation to prevent flash‑sale messages from saturating queues used by regular transactions

Database sharding for hot data, aware of distributed‑transaction challenges

2.2 Nginx Design Details

Static‑dynamic separation: serve static resources directly without passing through Tomcat

gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_comp_level 3;
gzip_disable "MSIE [1-6]\\.";
gzip_types text/plain application/x-javascript text/css application/xml text/javascript image/jpeg image/gif image/png;

Configure upstream server pool and failover settings (fail_timeout, max_fails, proxy_connect_timeout)

upstream netitcast.com {
        server 127.0.0.1:8080;
        server 127.0.0.1:38083;
        server 127.0.0.1:8083;
}
server {
        listen       88;
        server_name  localhost;
        location / {
                proxy_pass http://netitcast.com;
                proxy_connect_timeout 1;
                fail_timeout 5;
        }
}

2.3 Page‑Optimization Details

Consolidate JS/CSS files to reduce HTTP requests

Use small images and avoid large media on flash‑sale pages

2.4 Redis Cluster Usage

Distributed pessimistic lock for stock decrement

Cache hot inventory data; optionally use local cache with DB consistency checks

Distributed Pessimistic Lock

Set expiration on lock to avoid deadlock if a thread crashes

Loop with fast feedback: on lock timeout, re‑read stock and retry quickly

2.5 Captcha Design for Flash‑Sale

Answer‑captcha or random delay to deter automated tools

Measure response time; requests faster than human threshold are considered bots

Optionally embed MD5‑hashed answers with user‑specific salts to avoid server round‑trips

2.6 Transaction Compromise for High Concurrency

Split large transaction (stock decrement + order creation) into smaller ones to increase throughput

When sharding databases, accept distributed‑transaction complexity and use log‑based reconciliation if needed

2.7 Message‑Queue Rate Limiting

Use RocketMQ consumer thread pools and built‑in throttling to smooth order flow across microservices (order, inventory, points, user‑product).

3. Key Takeaways

Balance transaction atomicity with performance; consider splitting or compensating transactions

Avoid single points of failure across all layers

Implement graceful degradation (temporarily disable non‑essential features during peak load)