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

Today we explore the architecture of a flash‑sale (秒杀) system from seven different dimensions, outlining the essential components and design considerations needed to handle massive, bursty traffic.

Nginx + front‑end/back‑end separation + CDN caching + gateway (rate‑limit & circuit‑break)

Routing layer with Redis for hot‑data caching and distributed locks

MQ cluster for decoupling order processing

Business‑logic processing layer

Database layer with read‑write separation and hot‑data isolation

1. Characteristics of Flash‑Sale Business

Sudden massive page refreshes

Sudden massive purchase attempts

Potential malicious competition from automated “flash‑sale bots”

2. Overall Design Ideas

2.1 Peak‑Limiting and Rate‑Limiting

Front‑end + Redis intercept: only requests that successfully decrement a Redis counter are forwarded downstream

MQ buffers orders, protecting the business‑logic layer from overload; consumers pull tasks according to their processing capacity

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

2.2 Security Protection

Front‑end validation to prevent early purchases and duplicate clicks

IP‑rate limiting, UserID‑rate limiting, captcha challenges, and time‑based response analysis to block bots

IP/User blacklists

Overload shedding: drop requests when QPS or CPU exceeds a threshold

2.3 Page Optimization (Static‑Dynamic Separation)

Keep flash‑sale pages lightweight: small images, minimal JS/CSS, and separate static resources

Use asynchronous UI updates for the purchase process to avoid full page reloads

Configure Nginx to serve static files directly (no Tomcat) and enable gzip compression

Optionally use Varnish to cache static assets in memory

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 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;

2.4 Nginx Design Details

Static‑dynamic separation: static files are served directly by Nginx, bypassing Tomcat

2.5 Message‑Queue Rate Limiting

Use RocketMQ’s consumer thread pool and built‑in throttling to limit the flow of order messages across micro‑services such as order, inventory, points, and coupon services.

2.6 Database Design

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

Consider sharding for read‑write separation and hotspot isolation, aware of distributed‑transaction complexities

Typical SQL for inventory decrement:

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

2.7 Captcha Design for Flash‑Sale

Use answer‑captcha to deter automated bots; the verification includes both correctness and response time (e.g., human response >1.5 s)

Two approaches: refresh the question on failure (higher server load) or validate locally with pre‑hashed answers (lower load)

3. Important Considerations

Transaction compromise: split large transactions into smaller ones (e.g., inventory update vs. order creation) to boost concurrency

Sharding introduces distributed‑transaction challenges; monitoring logs and manual reconciliation may be required to maintain consistency

By combining these techniques—layered routing, Redis‑based rate limiting, MQ buffering, asynchronous order handling, static‑dynamic separation, Nginx optimizations, and careful database design—a flash‑sale system can sustain extremely high QPS while preserving stability and user experience.