Mastering Flash‑Sale TPS: Scalable Backend Architecture for E‑commerce

Flash‑sale (秒杀) scenario

A flash‑sale event occurs when a large number of users compete for a limited inventory within seconds or minutes. The extreme concurrency makes the system’s ability to process transactions per second (TPS) the primary stability metric.

Transactions per second (TPS) significance

TPS measures how many complete business transactions—order creation, inventory deduction, payment—can be finished each second, covering both read and write operations. High TPS alone does not guarantee stability; architectural design, resource provisioning, and fault‑tolerance are equally critical.

Typical TPS requirements by system scale

Small e‑commerce : daily active users in the ten‑thousands; stable TPS around 100‑1,000 .

Medium e‑commerce : daily active users in the millions; peak TPS needs 10,000‑50,000 .

Large e‑commerce (e.g., Alibaba, JD during Double‑11) : daily active users in the hundreds of millions; peak TPS must exceed 100,000‑1,000,000 .

During load testing, if TPS reaches 50,000 and latency spikes or retransmissions appear, the system is considered unstable.

Design principle: layered filtering and early rejection

The core idea is to reject the overwhelming majority of useless requests before they reach the database. For example, when 1,000,000 users vie for 100 items, only 100 requests are meaningful; the remaining 99.99 % should be filtered out early.

Five‑layer architecture

Client layer : Use a CDN to cache static pages (HTML, CSS, JS, images) and deploy captchas or JavaScript challenges to block automated bots.

// Example: enable CDN caching for static assets
location /static/ {
    expires 30d;
    add_header Cache-Control "public";
}

Access layer : Apply rate limiting per user ID or IP address (e.g., token‑bucket algorithm) to discard excessive refreshes.

# Nginx rate limit example
limit_req_zone $binary_remote_addr zone=flashsale:10m rate=5r/s;
location /sale/ {
    limit_req zone=flashsale burst=10 nodelay;
}

Application layer : Store the flash‑sale status (started, ended, paused) in an in‑memory cache such as Guava, Caffeine, or a local hashmap. Reject requests when the activity is not active.

Cache layer : Pre‑deduct inventory in Redis using an atomic operation (Lua script or INCRBY). If the stock is insufficient, the request is rejected immediately.

# Lua script for atomic stock deduction
local stock = tonumber(redis.call('GET', KEYS[1]));
if stock <= 0 then
    return 0; -- out of stock
else
    redis.call('DECR', KEYS[1]);
    return 1; -- stock reserved
end

Database layer : Only requests that successfully passed the Redis stock check create an order record in the relational database. This minimizes write load on the DB.

The layered approach ensures that less than 0.01 % of incoming traffic reaches the database, dramatically reducing contention and latency.