How to Build a High‑Performance Flash‑Sale System: 7 Key Architecture Strategies

1. Characteristics of Flash Sale

Massive simultaneous page refreshes

Massive concurrent purchase attempts

Potential malicious bots (flash‑sale scripts)

2. Overall Design

2.1 Peak Limiting

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

MQ buffers orders, protecting the business layer; consumers fetch tasks according to their capacity

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

Security Protection

Front‑end validates activity start time and prevents duplicate clicks

IP/User‑ID rate limiting, captcha, and time‑based validation to block bots

IP and User‑ID blacklists

Overload discard: drop 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 refresh for purchase actions instead of full page reloads

Serve static resources via Nginx static separation or Varnish cache

Enable gzip compression for static files

Asynchronous Processing

After Redis lock succeeds, push subsequent business to a thread pool for async handling

Thread pool pushes tasks to MQ for downstream systems (order, inventory, payment, coupon)

Accept eventual consistency; use periodic log scanning to detect and fix problematic orders

Hotspot Isolation

Separate cluster nodes for flash‑sale traffic from normal traffic via Nginx routing

Isolate MQ for flash‑sale to avoid clogging other services

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

Avoid single points of failure; degrade non‑essential features during peak

2.2 Nginx Design Details

Static/dynamic separation, avoid Tomcat for static resources

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 with appropriate settings

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 fail_timeout, max_fails, proxy_connect_timeout for 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.4 Redis Cluster Usage

Distributed pessimistic lock

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

2.5 Message Queue Rate Limiting

Use MQ (e.g., RocketMQ) consumer thread pool and built‑in throttling to smooth traffic across micro‑services (order, inventory, points, product).

2.6 Database Design

Split transactions to improve concurrency

Consider read/write separation and hot‑spot sharding, aware of distributed‑transaction complexity

Typical operation:

update inventory set stock = stock - 1 where id = ? and stock > 1

2.7 Captcha Design

Two approaches: refresh on failure (high interaction) or validate client‑side without refresh (MD5‑encrypted answers with user‑ID salt)

Measure response time; sub‑second answers may indicate bots

3. Important Considerations

Compromise on transaction scope to boost concurrency (e.g., split inventory decrement from order creation)

Sharding introduces distributed‑transaction challenges; rely on log analysis for manual reconciliation if needed