How to Build a High‑Performance Flash‑Sale System: Architecture & Best Practices

1. Characteristics of Flash‑Sale Business

Massive simultaneous page refreshes

Huge burst of purchase requests

Potential malicious bots competing for slots

2. Overall Design Overview

The system is divided into several layers: Nginx + front‑end/back‑end separation + CDN cache + gateway (rate‑limit + circuit‑breaker), routing cluster + Redis (hot data cache, distributed lock), MQ cluster, business processing layer, and database layer (read‑write separation, hot‑spot isolation).

2.1 Peak‑Limiting and Flow Control

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

MQ buffers orders, protecting the business layer; consumers fetch tasks based on their capacity.

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

2.2 Nginx Design Details

Static‑dynamic separation: serve static assets directly without Tomcat.

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

Enable gzip compression to reduce static file size.

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;

Cluster load‑balancing and failover parameters: fail_timeout 10s, max_fails 1, proxy_connect_timeout for backend handshake timeout.

upstream netitcast.com {
    # server cluster name
    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

Keep page assets minimal: small images, lightweight JS/CSS, and separate static from dynamic content.

Use asynchronous refresh for purchase actions to avoid full page reloads.

Serve static resources via Nginx static handling or Varnish memory cache.

2.4 Redis Cluster Applications

Distributed (pessimistic) lock for high contention.

Cache hot inventory data; optionally use local cache with DB‑controlled consistency when QPS is extreme.

2.5 Message‑Queue Rate Limiting

Leverage built‑in consumer thread pools and throttling in RocketMQ (or similar) to smooth order, inventory, points, and user‑product flows.

2.6 Database Design

Split transactions to improve concurrency: separate inventory deduction from order creation, coupon deduction, and points updates.

Consider read‑write separation and hot‑spot sharding, aware of distributed‑transaction overhead.

Typical SQL for inventory deduction:

UPDATE inventory SET stock = stock - 1 WHERE id = ? AND stock > 1;

2.7 Captcha Design for Anti‑Bot Protection

Two approaches: (a) Fail‑then‑refresh captcha (high interaction, reduces bot success); (b) Fail‑then‑show error without refresh, using client‑side JS verification with MD5‑encrypted answers tied to userId.

Measure response time; e.g., answers under 1 s may be flagged as automated.

3. Precautions and Trade‑offs

Split large transactions where possible to increase throughput.

Sharding introduces distributed‑transaction complexity; monitor and handle via logs if needed.

Implement overload protection: discard requests when QPS or CPU exceeds thresholds.