Designing a High-Concurrency Flash Sale System Architecture

1. Characteristics of Flash Sale Business

Massive instantaneous page refreshes

Massive instantaneous purchase attempts

Potential malicious competition using bots

2. Overall Design

2.1 Peak‑shaving and Rate Limiting

Front‑end + Redis intercepts requests; only successful Redis decrement proceeds downstream

MQ buffers orders, protecting downstream processing; consumers pull tasks based on capacity

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

Security Protection

Front‑end validates activity timing and prevents duplicate clicks

IP/User‑ID rate limiting, captcha challenges, and blacklist mechanisms

Overload discard: drop requests when QPS or CPU exceeds thresholds

Page Optimization and Static‑Dynamic Separation

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

Use asynchronous refresh for purchase actions to avoid full page reloads

Leverage Nginx static‑dynamic separation and gzip compression

Optionally integrate Varnish for in‑memory static caching

Asynchronous Processing

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

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

Accept eventual consistency; use periodic logs to detect and reconcile anomalies

Hotspot Isolation

Avoid flash‑sale load impacting normal services by separating traffic at Nginx, MQ, and database layers, using middleware configurations for hot‑cold segregation.

Nginx routes flash‑sale traffic to dedicated server pool

Separate MQ topics to prevent flash‑sale messages from clogging regular queues

Consider database sharding for hot data, weighing distributed‑transaction complexity

Eliminate single points of failure and implement graceful degradation

2.2 Nginx Design Details

Static‑dynamic separation for static resources

server {
    listen 8088;
    location ~ \.(gif|jpg|jpeg|png|bmp|swf)$ {
        root /usr/local/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 load balancing and failover parameters.

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

Integrate Varnish for static caching

Integrate tengine for overload protection

2.3 Page Optimization Details

Reduce Interaction Pressure

Consolidate JS/CSS into few files to minimize requests

Avoid large or excessive images on flash‑sale pages

Security Controls

Validate time window on both client and server

Use asynchronous purchase via AJAX instead of full page reloads

Redis for IP and User‑ID rate limiting

2.4 Redis Cluster Applications

Distributed (pessimistic) locks

Cache hot data (inventory); fallback to local cache with DB consistency if QPS is extreme

Distributed Pessimistic Lock

Use lock with expiration to avoid deadlock

Implement rapid retry loops with timeout feedback for inventory checks

Asynchronous Order Processing

After acquiring Redis lock, record user info, release lock, and process order asynchronously

Cache user info in Redis, trigger persistence, and periodically reconcile consistency

2.5 Message Queue Rate Limiting

Use MQ (e.g., RocketMQ) consumer thread pools and built‑in throttling to smooth traffic spikes across microservices such as order, inventory, points, and product services.

2.6 Database Design

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

Consider sharding with read/write separation and hotspot isolation, aware of distributed‑transaction challenges

Key operations: decrement inventory, create order, generate pending payment, deduct coupons, adjust points.

Example SQL: UPDATE inventory SET stock = stock - 1 WHERE id = ? AND stock > 1;

2.7 Captcha Design for Answer‑Based Challenges

Mitigate bot interference and spread request load

Two approaches: refresh captcha on failure (high interaction) or static JS validation with encrypted answers (low interaction)

Validate not only correctness but also response time; sub‑second answers may indicate automation.

3. Important Considerations

To achieve high concurrency, compromise on transaction granularity:

On a single node, split large transaction (inventory + order + coupon + points) into two smaller ones

When sharding, handle distributed‑transaction complexities, possibly using log‑based reconciliation to avoid severe blocking.