Designing a High-Performance Flash-Sale System: 7 Key Architectural Strategies

1. Characteristics of Flash‑Sale Business

Massive simultaneous page refreshes

Massive concurrent purchase attempts

Potential malicious competition using bots

2. Overall Design

2.1 Peak‑Limiting and Rate‑Limiting

Front‑end + Redis interception; only requests that successfully decrement a Redis token proceed downstream

MQ queues buffer orders, protecting the business‑logic layer; consumers fetch tasks according to their capacity

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

2.2 Nginx Design Details

Static resources are served directly by Nginx (static‑dynamic separation) and gzip compression is enabled.

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

Gzip configuration:

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;

Upstream cluster example:

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

Keep flash‑sale pages lightweight: small images, minimal JS/CSS, static‑dynamic separation

Use asynchronous refresh for purchase actions instead of full page reloads

Enable Nginx static‑resource caching or Varnish in‑memory cache

Enable gzip compression to reduce bandwidth

2.4 Security Controls

Front‑end validation to prevent early or duplicate purchases

IP and User‑ID rate limiting, blacklists, and captcha challenges

Reject requests when QPS or CPU exceeds thresholds

2.5 Redis Cluster Usage

Distributed pessimistic lock for inventory deduction

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

Set lock expiration to avoid deadlocks and implement fast feedback loops

2.6 Message‑Queue Rate Limiting

Use MQ (e.g., RocketMQ) consumer thread pools and built‑in throttling to smooth order flow.

2.7 Database Design

Separate read/write and hot‑data partitions; consider sharding but be aware of distributed‑transaction complexity

Split transaction: inventory deduction as a small transaction, other operations (order creation, coupon, points) as a larger one

SQL example:

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

2.8 Captcha Design for Flash Sale

Answer‑type captcha slows down bots and spreads traffic

Validate response time; extremely fast answers are treated as automated