Flash Sale — Tiered (Waiting Room + Bot Detection + CDN Edge)

The tiered flash sale architecture is the production-grade approach used by platforms like Nike SNKRS, Ticketmaster, and Amazon Lightning Deals to handle 50M+ concurrent users competing for limited-quantity inventory. It solves two problems that the Queue variant leaves unaddressed: bot/scalper exploitation and traffic volume that overwhelms even application-level queues.

The first problem is bots. In the Queue variant, automated scripts join the virtual queue microseconds after sale start, securing top positions ahead of human users. Without bot mitigation, scalpers capture 30-50% of limited-edition inventory using purpose-built software. Device fingerprinting — analyzing browser canvas hash, WebGL renderer, timezone, installed fonts, mouse movement patterns, and request timing — detects bots with ~95% accuracy and ~1-2% false positive rate. The BotDetector service sits between the API Gateway and the Load Balancer, filtering automated requests before they reach inventory.

The second problem is scale. At 50M concurrent users, even the API Gateway receives 10M+ RPS at sale start. Application-level components cannot absorb this traffic economically. The solution is pushing admission control to the network edge: a CloudFront CDN with Lambda@Edge implements a virtual waiting room across 400+ global edge locations. The Lambda@Edge function assigns queue positions, issues admission tokens, and returns a waiting page — all without any traffic reaching the origin. Only admitted users (5K/sec globally) proceed to the API Gateway. This absorbs 90%+ of traffic at the CDN edge.

The tiered inventory architecture combines Redis for the fast reservation path with PostgreSQL for durable persistence. Redis atomic DECR provides sub-millisecond inventory checks with zero overselling. PostgreSQL stores the durable order records and provides a reconciliation baseline for Redis every 30 seconds. If Redis fails, the system falls back to PostgreSQL (with higher latency but maintained correctness). The tiered approach gives both speed and durability.

VIP priority adds a business dimension to the technical architecture. Lambda@Edge reads the user's loyalty tier from a signed JWT claim and assigns priority queue positions — Gold and Platinum customers skip ahead in the waiting room. This maximizes revenue per sale: VIP customers have 20x higher lifetime value and 3x higher conversion rates. The waiting room maintains FIFO ordering within each tier.

The async processing pipeline handles payment and confirmation via Kafka. PaymentWorker processes payments asynchronously (~200ms per transaction), updates order status, and releases stock back via Redis INCR on failure. ConfirmationWorker sends email and push notification confirmations. The entire post-reservation pipeline is decoupled from the purchase path.

The global distribution aspect adds another layer of complexity. With 50M users across multiple continents, the CDN edge waiting room must coordinate token release across 400+ edge locations. Lambda@Edge functions at each PoP maintain local counters that synchronize with a central budget allocator every 100ms. Each edge location receives a token budget (e.g., 50 tokens/sec for a US-East PoP, 5 tokens/sec for a Singapore PoP) proportional to its traffic share. This distributed admission control prevents any single region from consuming all available inventory while maintaining globally consistent release rates.

The operational complexity of the tiered approach is significant. Monitoring dashboards must track metrics at every layer: CDN hit rate, Lambda@Edge cold start frequency, bot detection accuracy and false positive rate, admission token utilization, Redis DECR throughput, PostgreSQL reconciliation drift, Kafka consumer lag, and payment success rate. Alerting thresholds at each layer enable rapid diagnosis when the system degrades — the layered architecture makes it possible to isolate the failing component quickly.

This architecture represents the frontier of flash sale system design. Interviewers at FAANG companies expect senior candidates to discuss CDN-edge traffic absorption, bot detection trade-offs (accuracy vs false positives), VIP prioritization business justification, and tiered storage with reconciliation. The progression from Naive to Queue to Tiered demonstrates deepening understanding of the distributed systems challenges in high-contention inventory management.

The tiered flash sale system uses 12 components organized into four defense layers: CDN edge (Client, CDN, WaitingRoom), security and routing (ApiGateway, BotDetector, LoadBalancer), core transaction (SaleService, InventoryCache, InventoryDB), and async processing (OrderStream, PaymentWorker, ConfirmationWorker).

The first defense layer is the CDN edge. All traffic enters through CloudFront CDN, which serves cached product pages and availability data with a 2-second TTL (95% cache hit rate for GET requests). Purchase attempts trigger Lambda@Edge — the virtual waiting room. Lambda@Edge assigns a queue position based on arrival time and user tier (VIP users get priority positions), issues an admission token with 5-minute TTL, and returns a waiting page. The function executes at the edge location closest to the user, so no traffic crosses the internet to reach the origin. Lambda@Edge releases 5000 admission tokens per second globally — only token-holders proceed further.

The second defense layer is security and routing. Admitted users hit the API Gateway, which validates the admission token and JWT authentication (~3ms), enforces a 100K RPS rate limit, and routes purchase requests through the BotDetector. The BotDetector analyzes device fingerprint (canvas hash, WebGL renderer, fonts, timezone), behavioral signals (mouse movement, typing patterns), and request timing. Requests scoring above the 0.85 bot confidence threshold are rejected (429 Too Many Requests). Clean requests proceed to the Load Balancer, which distributes across SaleService pods via least-connections algorithm.

The third layer is core transaction processing. SaleService receives ~5K purchase requests per second (down from 10M at CDN edge — a 2000x reduction). It validates the admission token, performs an atomic DECR on InventoryCache (Redis) for instant stock reservation, persists the order to InventoryDB (PostgreSQL) for durability, and publishes an order event to OrderStream (Kafka). InventoryCache and InventoryDB are reconciled every 30 seconds to ensure consistency.

The fourth layer is async processing. OrderStream (Kafka, 64 partitions) carries order events to PaymentWorker and ConfirmationWorker. PaymentWorker calls the external payment gateway (~200ms), updates order status in InventoryDB, and triggers Redis INCR on payment failure to release reserved stock. ConfirmationWorker sends email confirmations via SES and push notifications via SNS.

The reconciliation process between InventoryCache (Redis) and InventoryDB (PostgreSQL) runs every 30 seconds. A background reconciliation job compares the Redis stock counter with the count of non-expired orders in PostgreSQL for each item. If drift is detected (e.g., a Redis INCR was lost due to a network partition during a payment failure), the reconciliation job corrects the Redis counter. This ensures that over time, Redis and PostgreSQL converge to the same stock count, even in the presence of transient failures.

The ConfirmationWorker is the final component in the pipeline. It consumes order events from Kafka after PaymentWorker has updated the order status, and sends email confirmations via SES and push notifications via SNS. With 10 workers and 30ms processing time, it handles the confirmation volume with generous headroom. Confirmation delivery is best-effort — if SES or SNS fails, the worker retries with exponential backoff but does not block the pipeline.

The architecture provides defense-in-depth against both traffic overload and adversarial actors. Each layer reduces the traffic that reaches the next: CDN edge absorbs 90% (10M to 50K), bot detection filters 10% of remainder (50K to 45K), and only 5K/sec of verified, admitted, human purchase attempts reach the inventory system. This layered reduction is the key architectural pattern.