E-Commerce Flash Sale (100k TPS)

Architecture for handling 100,000 requests per second without dropping a single order

⏱ 20 min⚡ Interactive Tool📊 Diagram

A flash sale is the most brutal test of system resilience: 1 million users hit 'Buy Now' simultaneously for 100 items. The system must handle 100,000 TPS at peak, maintain zero overselling, and respond in under 100ms — all while protecting the relational database from instant collapse.

Key Concepts

Traffic Shaping & Token Bucket

API Gateway + Redis rate limiter drops excess traffic before it reaches application pods. A virtual waiting room (Redis List) accepts 10,000 requests; the remaining 990,000 get HTTP 429 Retry-After instantly.

Redis Atomic Inventory (Lua Script)

Stock count lives exclusively in Redis RAM during the sale. Redis Lua script runs in single-thread memory atomic block. Only 100 successful DECRs return true; 999,900 return stock_depleted in <2ms.

Kafka Async Order Buffering

10,000 accepted orders are pushed into Kafka topics instantly instead of direct SQL INSERTs. Worker pool consumes at a controlled 500 writes/sec to PostgreSQL, preventing connection pool exhaustion.

HA & Circuit Breaking

Redis Sentinel/Cluster failover + PgBouncer connection pooling ensures single component failure never cascades. Envoy circuit breakers trip if downstream latency exceeds 200ms.

⚡ Interactive Architecture Simulator

Redis Atomic Lua + Kafka Order Buffer (Recommended)Recommended

99.9% requests handled in Redis RAM. Orders buffered in Kafka and consumed at steady DB write speed (500 TPS).

PostgreSQL Optimistic Locking (SELECT FOR UPDATE)High Risk

All 100k TPS directly query PostgreSQL rows. Optimistic version check reverts failed transactions.

Distributed Lock (Redlock) + Sync DB WriteBaseline

Acquires distributed Redis lock per item before synchronous PostgreSQL write.

100,000 TPS

Throughput Capacity

12%

Peak DB CPU Load

15ms

P99 Response Latency

Infrastructure Cost

Architectural Assessment & Bottleneck Analysis

Production Grade ✓ — Database CPU stays under 15%. Zero overselling guaranteed via atomic Redis DECR script.

Capacity Estimation & Hardware Math

Before writing system design code, senior engineers calculate capacity constraints for throughput, memory, bandwidth, and database write IOPS:

Metric / Constraint	Calculation Formula & Raw Value	Architectural Implication
Peak Concurrent Users	1,000,000 users in 5 seconds window	Requires CDN Edge caching for all static assets (HTML/JS/Images).
Peak Request TPS	1,000,000 / 10s peak window = 100,000 TPS	API Gateway (Kong/Envoy) must load balance across 50+ K8s pods.
Redis Stock Key Memory	10,000 SKUs × 64 bytes = ~640 KB RAM	Entire flash sale stock easily fits into a single Redis primary node RAM.
DB Sustainable Write Speed	PostgreSQL 16 with NVMe SSD = 1,000 writes/sec max	Kafka buffer is mandatory to throttle 100k TPS down to 500 writes/sec.

Architecture Blueprint

Production Code Snippet 1: Atomic Redis Lua Script

This Lua script runs inside Redis memory as a single atomic operation. Even if 100,000 threads execute it simultaneously, Redis processes them sequentially without race conditions:

decrement-stock.lualua
-- Redis Lua script for atomic stock decrement
-- KEYS[1]: stock key, e.g., "flash:stock:item-101"
-- ARGV[1]: requested quantity (e.g., 1)
-- ARGV[2]: user_id (for duplicate prevention)

local stock_key = KEYS[1]
local user_bought_key = "flash:bought:" .. ARGV[2]
local quantity = tonumber(ARGV[1])

-- Step 1: Prevent duplicate purchase by same user
if redis.call('EXISTS', user_bought_key) == 1 then
  return -2  -- Code -2: User already bought item
end

-- Step 2: Check current stock count
local current_stock = tonumber(redis.call('GET', stock_key))

if current_stock == nil or current_stock < quantity then
  return 0   -- Code 0: Insufficient stock (Sold Out!)
end

-- Step 3: Atomic Decrement & Mark user as purchased
redis.call('DECRBY', stock_key, quantity)
redis.call('SET', user_bought_key, "1", "EX", 86400) -- TTL 24h

return current_stock - quantity -- Return remaining stock count

Production Code Snippet 2: Kafka Async Order Consumer

The worker pool pulls order events from Kafka at a controlled rate and writes to PostgreSQL inside an idempotent SQL transaction:

order-consumer.tstypescript
import { Kafka } from 'kafkajs';
import { Pool } from 'pg';

const pgPool = new Pool({ max: 20, idleTimeoutMillis: 30000 });
const kafka = new Kafka({ clientId: 'order-worker', brokers: ['kafka:9092'] });
const consumer = kafka.consumer({ groupId: 'flash-sale-group' });

export async function startOrderConsumer() {
  await consumer.connect();
  await consumer.subscribe({ topic: 'flash-sale-orders', fromBeginning: false });

  await consumer.run({
    eachBatchAutoResolve: false,
    eachBatch: async ({ batch, resolveOffset, heartbeat }) => {
      const client = await pgPool.connect();
      try {
        await client.query('BEGIN');
        for (const message of batch.messages) {
          const order = JSON.parse(message.value.toString());
          
          // Idempotent SQL INSERT with ON CONFLICT DO NOTHING
          await client.query(
            `INSERT INTO orders (order_id, user_id, item_id, status, created_at)
             VALUES ($1, $2, $3, 'CONFIRMED', NOW())
             ON CONFLICT (order_id) DO NOTHING`,
            [order.orderId, order.userId, order.itemId]
          );
          resolveOffset(message.offset);
        }
        await client.query('COMMIT');
      } catch (err) {
        await client.query('ROLLBACK');
        console.error('DB Write Error in Kafka Batch:', err);
      } finally {
        client.release();
        await heartbeat();
      }
    },
  });
}

Architecture Trade-off Matrix

Strategy Model	Peak TPS Capacity	DB CPU % @ Peak	Overselling Safety
Redis Lua + Kafka (Recommended)	100,000 TPS	< 15% CPU	100% Guaranteed Zero Oversell
Postgres SELECT FOR UPDATE	2,500 TPS	100% (Crashes DB)	High Connection Timeout Risk
Redlock Distributed Lock	15,000 TPS	~ 55% CPU	Safe, but high latency overhead

💡

Senior Architect Insight: The secret weapon: isolate flash sale inventory inside Redis RAM before the sale starts. Redis Lua DECR from 100 → 0 is atomic and handles 100,000 concurrent requests in memory. The 999,900 losers get a Redis 0-stock response in <2ms and never touch the relational database.

Previous🔄 Saga Transaction Machine Simulator

Next LessonUber-like Ride Sharing Platform