How to Build a 100k+ TPS Flash‑Sale System with 7 Layered Defense Strategies

1. Core Idea: Layered Filtering (Funnel Model)

Flash‑sale (seckill) systems act as a massive traffic funnel; the goal is to intercept >99.9% of requests before they reach the database by applying rate‑limiting, filtering, or degradation at each layer (frontend → gateway → application → cache → MQ → DB).

2. Seven Architecture Techniques and Implementation

Technique 1: Front‑end Optimization – Peak‑shaving & Anti‑cheat

Button disable + millisecond countdown – prevents multiple clicks before the sale starts.

CAPTCHA / arithmetic challenge – slows down submissions, can adjust difficulty based on current QPS.

Request throttling – enforce a minimum interval (e.g., 300 ms) per IP/UID on the client side.

Static page + CDN – serve HTML/CSS/JS/images of the seckill page from CDN, leaving the application to handle only core API calls.

Effect: Over 70 % of invalid traffic is filtered out early, dramatically reducing entry‑point pressure.

Technique 2: Gateway Protection – Traffic Scheduling & Black‑market Blocking

Rate limiting – token‑bucket or leaky‑bucket algorithms, with strict thresholds for the seckill API.

Circuit breaking & fast fail – gateway rejects requests when downstream is overloaded, returning “seckill busy, try later”.

Anti‑fraud service – integrates risk control to detect abnormal patterns (rapid clicks, identical UA/IP) and dynamically bans IPs or users.

Consistent‑hash load balancing – routes the same user to the same backend node, improving cache hit rate and reducing cross‑node contention.

Experience: Limiting at Nginx/Gateway is the cheapest and most effective optimization.

Technique 3: Cache Layer – “Read‑many Write‑few”

Product detail cache – store product info, price, status in Redis; refresh via periodic warm‑up or message‑driven updates.

Stock cache – atomic DECR seckill:stock:{productId} in Redis; if result < 0, roll back stock and reject request.

Hot‑key protection – use SETNX + EXPIRE as a distributed lock to prevent cache breakdown; set reasonable TTL to avoid cache avalanche.

Redis boosts QPS from 10 k to over 100 k, becoming the key performance accelerator.

Technique 4: Asynchrony & Message Queue – “Water Tank”

After a successful pre‑deduction, the request writes a message to Kafka/RocketMQ, returns “seckill success, order processing” to the client, and lets backend workers consume the message to create orders and finally deduct stock in the DB.

Without a queue the system behaves like an exploding timer.

Technique 5: Stock Deduction – Precise Control & Consistency

Redis layer performs fast pre‑deduction: DECR seckill:stock:{productId} Result ≥ 0 → success; < 0 → rollback.

Database layer finalizes deduction with optimistic lock:

UPDATE product_stock SET stock = stock - 1 WHERE product_id = ? AND stock > 0;

If the DB update fails, the Redis stock is restored.

Redis provides speed, DB provides accuracy; together they ensure eventual consistency.

Technique 6: Statelessness & Elastic Scaling

Application stores no session; all state lives in Redis, allowing any node to handle any request.

Containerized deployment with Kubernetes + HPA automatically scales pods based on CPU/QPS; readiness probes prevent traffic to unready pods.

Cold‑start optimization by pre‑loading hot data and JIT warm‑up for sub‑second response on new nodes.

The system can “breathe automatically” to handle any traffic surge.

Technique 7: Resource Isolation & Degradation Protection

Business isolation – dedicated seckill cluster and database, separate Redis/MQ.

Data isolation – separate order and stock tables from the main site.

Degrade & circuit‑break – if Redis fails, fall back to DB mode; if MQ backs up, return “queueing” and limit traffic; non‑core services (points, coupons) are automatically circuit‑broken.

Principle: Prefer degradation over downtime.

3. Complete Seckill Flow (Simplified)

[User clicks button]
↓
[API gateway rate‑limit + anti‑scrape]
↓
[Application layer]
  → Validate eligibility
  → Redis stock DECR
  → Enqueue to Kafka
  → Return “queueing”
↓
[Message queue]
↓
[Worker consumes]
  → DB stock deduction (optimistic lock)
  → Create order
  → Rollback stock on failure
↓
[User checks result] → Polling / push order status

4. Advanced Optimizations & Pitfalls

Idempotency – each user can order a product only once, using SETNX seckill:success:{userId}:{productId}.

Cache consistency – delayed double delete + MQ async notification to keep Redis and DB in sync.

Hot‑key sharding – split a stock key into multiple sub‑keys (e.g., stock:1001:1, stock:1001:2) to reduce contention.

Database sharding – horizontal partitioning of orders and stock by product or user ID.

5. Monitoring & Stress‑Testing

Metrics: Redis QPS / hit rate, Kafka backlog, API gateway limit hits, seckill success / oversell rate.

Load testing: use Gatling or JMeter to simulate millions of concurrent users; adopt gray release and gradual ramp‑up; establish an end‑to‑end seckill pressure‑test pipeline.

6. Summary

By combining front‑end peak‑shaving, gateway rate‑limiting, Redis caching, asynchronous queue processing, optimistic‑lock persistence, stateless elastic scaling, and isolation with graceful degradation, a flash‑sale system can sustain 100 k+ TPS while maintaining high availability and data consistency.