A production-grade distributed flash sale and inventory reservation engine engineered to handle massive concurrent traffic while guaranteeing zero overselling using Redis atomic operations, asynchronous event processing, and scalable microservices.
The mission was specific and brutal:
Handle 200,000+ concurrent requests competing for only 40,000 stock items (e.g., iPhones) during a Flash Sale.
The system needed to guarantee three things:
- Fairness: No overselling. First come, first served. Race conditions must be handled atomically.
- Speed: Most users will fail to buy, but they must fail fast (low latency). They cannot see a loading spinner.
- Uptime: The high traffic on the "Buy" button must not crash the "Login" page.
Our first attempt was a standard Monolithic Architecture. All logic (Auth, Order, Stock) lived in one Node.js process.
-
The "Auth Choke": When 10,000 users tried to login at 10:00 AM, the CPU hit 100% just hashing passwords. This choked the Stock Check, causing the "Buy" button to freeze for users who were already logged in.
-
The "One-Kill-All" Bug: A single memory leak in the Order processing crashed the entire server, taking down the Storefront and Inventory with it.
-
Scale Limits: We could handle ~2,000 users. Beyond that, vertical scaling (bigger RAM) became too expensive and inefficient.
To break the 10k barrier and aim for 100k+, we tore it down and rebuilt it as a Distributed System on Kubernetes.
-
Concurrency & Fairness: We implemented Optimistic Locking at the Database layer. Even if 100 users click "Buy" at the exact same millisecond, the database processes them sequentially. No overselling.
-
Architectural Isolation:
- Scenario: Auth Service is getting hammered (DDoS or Flash Crowd).
- Outcome: The
auth-servicepods scale up to 100% CPU. BUT, theorder-serviceruns on separate pods. Users already inside the app experience Zero Lag while checking out.
-
Infinite Scaling: While the target was 10k, this architecture can theoretically handle 100k or 1M users simply by increasing the
maxReplicasin the HPA configuration.
We simulated a massive "Flash Sale" load using k6 (Load Testing) and monitored the Kubernetes HPA (Auto-scaler).
Engineered a distributed system capable of handling 208,000+ requests in 2 minutes (1,700 RPS) with ZERO overselling on a strict 40,000 inventory limit using Redis.
| Service | 🔐 Auth Service | 📦 Stock Service | 🛒 Order Service |
|---|---|---|---|
| Role | The Gatekeeper | The Fast Reader | The Transaction Manager |
| Test Scenario | Extreme Load (1,700 RPS) | Extreme Load (1,700 RPS) | Extreme Load (1,700 RPS) |
| Workload Type | CPU Bound (bcrypt hashing) | I/O Bound (Fast DB Reads) | Network Bound (Internal API calls) |
| Peak CPU Load | Auto-scaled successfully | Auto-scaled successfully | Auto-scaled successfully |
| Throughput | ~1,700 Req/Sec (Combined) | ~1,700 Req/Sec (Combined) | ~1,700 Req/Sec (Combined) |
| Latency (Avg) | Maintained under load | 10 ms (Instant) ⚡ | Maintained under load |
| Scaling Action | Scaled across K8s Pods | Scaled across K8s Pods | Scaled across K8s Pods |
| Verdict | ✅ SURVIVED (208k+ Reqs) | ✅ SURVIVED (Zero Oversell) | ✅ SURVIVED (40k Orders) |
Engineer's Note: The system demonstrated Dependency Propagation Resilience. When
Order Servicewas stressed, it naturally stressed theStock Service. Both auto-scaled in tandem without human intervention, maintaining 100% uptime.
- Core: Node.js, Express.js (Microservices)
- Orchestration: Kubernetes (K8s), Docker
- Gateway: Nginx Ingress Controller, Custom Node.js Gateway
- Data Layer: MongoDB (Per-Service DB), Redis (Caching)
- Testing: k6 (Performance), Postman (API)
- Observability: Kubernetes Metrics Server
- Deploy Infrastructure:
kubectl apply -f K8s/- Simulate Traffic:
k6 run scripts/stress-test.js- Monitor Scaling:
kubectl get hpa -wArchitected & Engineered by Gaurav