Designing a High‑Concurrency Flash Sale (秒杀) System Architecture

We discuss the architecture of a flash‑sale (秒杀) system from seven different dimensions, outlining the main knowledge points such as Nginx + front‑back separation + CDN cache + gateway (rate limiting + circuit breaking), clustered routing with Redis (caching hot data, distributed lock), MQ cluster, business processing layer, and database layer (read/write separation, hotspot isolation).

1. Characteristics of Flash‑Sale Business

Massive simultaneous page refreshes.

Massive simultaneous purchase attempts.

Potential malicious competition using automated tools.

2. Overall Design

2.1 Peak‑Limiting and Rate‑Limiting

Front‑end + Redis intercepts requests; only those that successfully decrement Redis can proceed downstream.

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

Introduce answer‑type captchas and random request sleep to smooth traffic spikes.

Security Protection

Front‑end validates activity start time and prevents duplicate clicks.

IP/User‑ID rate limiting, blacklists, and answer‑type captcha to block automated tools.

Overload discard: drop requests when QPS or CPU exceeds thresholds.

Page Optimization and Static‑Dynamic Separation

Keep flash‑sale page assets minimal (small images, lightweight JS/CSS) and separate static from dynamic content.

Use asynchronous refresh for purchase actions instead of full page reloads.

Leverage Nginx static separation, gzip compression, or Varnish caching.

Asynchronous Processing

After Redis lock acquisition, push subsequent business logic to a thread pool for async handling.

Thread pool tasks are placed into MQ for downstream systems (order, inventory, payment, coupon).

Accept reduced consistency for higher concurrency; use periodic log scans to reconcile anomalies.

Hotspot Isolation

Avoid flash‑sale load affecting normal services by isolating clusters, MQ, and databases; use middleware configuration for hot‑cold separation and avoid single points of failure.

2.2 Nginx Design Details

Static‑dynamic separation: static resources bypass 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;

Configure upstream load balancing and failover:

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

Reduce Interaction Pressure

Consolidate JS/CSS into few files to lower request count.

Avoid large or numerous images on flash‑sale pages.

Security Controls

Validate time window on both client and server.

Use asynchronous purchase via AJAX rather than full page reload.

Redis‑based IP and User‑ID rate limiting.

2.4 Redis Cluster Applications

Distributed (pessimistic) lock.

Cache hot data such as inventory; optionally use local cache with DB consistency.

Distributed Pessimistic Lock

Set expiration after lock acquisition to avoid deadlock.

Loop with quick feedback: if lock times out, retry reading inventory.

2.5 Message‑Queue Rate Limiting

Use MQ (e.g., RocketMQ) consumer thread pools and built‑in throttling to smooth spikes across microservices like order, inventory, points, and product services.

2.6 Database Design

Split transactions to increase concurrency.

Consider sharding, read/write separation, and hotspot isolation, while being aware of distributed‑transaction challenges.

Typical operations: decrement inventory, create order, generate pending payment, deduct coupons, adjust points. Example SQL:

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

2.7 Captcha Design for Answer‑Type Questions

Prevent automated tools and spread traffic over time.

Two approaches: refresh on failure (high server load) or validate locally with MD5‑encrypted answers tied to userId to avoid extra requests.

Measure response time; sub‑second answers may indicate bots.

3. Important Considerations

To achieve high concurrency, compromise on transaction scope: split inventory decrement from order creation, and handle distributed‑transaction issues via log analysis rather than strict two‑phase commit.