Designing a High‑Performance Flash‑Sale System: 7 Key Architecture Strategies

Today we discuss flash‑sale system architecture from seven dimensions.

Nginx + front‑back separation + CDN cache + gateway (rate‑limit + circuit‑break)

Cluster routing layer + Redis (cache hot data, distributed lock)

MQ cluster

Business processing layer

Database layer (read/write separation, hot‑spot isolation)

1. Characteristics of flash‑sale business

Massive simultaneous page refreshes

Massive concurrent purchase attempts

Potential malicious bots competing for the sale

2. Overall design

2.1 Peak‑shaving and rate limiting

Front‑end + Redis intercept; only requests that successfully decrement in Redis proceed downstream

MQ buffers orders, protecting the business layer; consumers pull tasks based on capacity

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

2.2 Nginx design details

Static resources served via Nginx with static‑dynamic separation, gzip compression, and optional Varnish caching.

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.3 Page optimization details

Keep flash‑sale page simple: small images, minimal JS/CSS, static‑dynamic separation

Use asynchronous refresh for purchase actions instead of full page reloads

Enable Nginx static‑dynamic separation and gzip; optionally use Varnish for in‑memory caching

2.4 Redis cluster usage

Distributed pessimistic lock for inventory decrement

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

2.5 Message‑queue throttling

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

2.6 Database design

Split transactions to improve concurrency (e.g., separate inventory decrement from order creation)

Consider sharding, read/write separation, hot‑spot isolation, aware of distributed‑transaction challenges

2.7 Captcha design

Answer‑question captcha to deter bots and spread request load

Two approaches: refresh on failure (high interaction) or static JS validation with encrypted answers and timing checks

3. Important considerations

Compromise on transaction scope to boost concurrency

When sharding, handle distributed‑transaction issues via logs or manual reconciliation