Designing a High‑Concurrency Flash Sale System Architecture

We examine flash‑sale system design from seven dimensions, focusing on a layered architecture that includes Nginx with front‑end/back‑end separation, CDN caching, and a gateway for rate‑limiting and circuit‑breaking; a routing layer backed by Redis for hot‑data caching and distributed locks; an MQ cluster to buffer orders; a business‑logic layer; and a database layer with read/write separation and hotspot isolation.

1. Characteristics of flash‑sale business – massive simultaneous page refreshes, rapid order attempts, and potential malicious bots (秒杀器) that compete for limited inventory.

2. Overall design ideas

Peak‑shaving and rate‑limiting: front‑end + Redis intercepts requests, only allowing those that successfully decrement stock to proceed; MQ buffers orders to protect downstream services; captcha and random sleep further smooth traffic.

Security protection: front‑end validates activity timing, prevents duplicate clicks, applies IP/UserId rate‑limits, maintains blacklists, and discards overload requests based on QPS/CPU thresholds.

Page optimization and static‑resource separation: keep flash‑sale pages lightweight, use Nginx static‑resource handling or Varnish caching, enable gzip compression.

Asynchronous processing: after Redis lock acquisition, push subsequent tasks to a thread pool and then to MQ for order, inventory, payment, and coupon services; tolerate eventual consistency to boost concurrency.

Hotspot isolation: separate clusters for routing, MQ, and databases to avoid contention; consider sharding with tools like ShardingJDBC while weighing distributed‑transaction complexity.

2.1 Nginx design details

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 servers with fail‑over settings:

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.4 Redis cluster usage

Distributed (pessimistic) lock with expiration to avoid dead‑locks.

Cache hot inventory data; optionally use a local cache with database‑controlled consistency.

2.7 Captcha design

Introduce answer‑based challenges to deter bots; measure response time (e.g., < 1 s may indicate automation).

Two approaches: server‑side verification with each wrong attempt (higher load) or client‑side MD5‑encrypted answers with server validation (lower load).

3. Precautions

Split large transactions (e.g., inventory decrement vs. order creation) to improve concurrency.

When sharding databases, be aware of distributed‑transaction overhead and plan for manual reconciliation if needed.

Overall, the architecture balances performance, reliability, and security to handle extreme traffic spikes typical of flash‑sale events.