Building products that solve at scale — across AI, RegTech, and consumer infra.

The 90-second problem

At 12:00:00 AM on day one of Big Billion Days, Flipkart's traffic doesn't ramp — it vertical-walls. From a baseline of ~120K concurrent users to roughly 1.6M in under 90 seconds, every one of them hitting the same three pages: home, deals, and the iPhone PDP.

The "buffering" people complain about isn't one problem. It's four overlapping failure modes, each with a different product owner.

Where the system actually breaks

• Database hot-keys. 1.6M users all reading the inventory row for iPhone 15. The row lives on one DB shard. The shard becomes a thermal hotspot. Reads queue. Page sits.
• Cache stampede. The deal-banner cache expires at 11:59:58. Two seconds later, 1.6M users find no cache, and 1.6M requests hit the origin simultaneously. The origin folds.
• Inventory locking. Only 8,000 iPhones exist. 400K users tap "Buy" inside 4 seconds. Each "Add to Cart" tries to reserve stock. The lock contention is the bottleneck — not the network.
• Payment gateway throughput. Razorpay / PayU have provisioned capacity. Once you've crossed it, every checkout sits in a queue you can't see.

Why they choose to buffer

Flipkart could over-provision to handle the peak with zero latency. It would cost roughly 18–22× normal infra for capacity used 4 hours a year. The product call is to under-provision deliberately and absorb the spike with three UX mechanics:

• Virtual waiting room. The "you're in queue" screen isn't a failure — it's a load shedder. It converts a 503 into a feeling of fairness.
• Pre-rendered deal pages. The home page during BBD is mostly static HTML served from CDN. No personalization. No DB calls. It looks dynamic; it isn't.
• Optimistic UI on cart. "Added to cart" shows instantly, even before the inventory reservation confirms. Most users don't notice the rollback when stock runs out — they just see "out of stock" 4 seconds later.

What "fix the buffering" would actually cost

Indexed cost vs current architecture, normalised. The buffering experience is, in PM terms, the cheapest possible solution that preserves trust.

The PM lesson

The Flipkart spinner is the most expensive UI component in Indian e-commerce. It exists because someone, somewhere, did the math and decided that 12 seconds of visible delay was worth ₹400 crore in unspent cloud spend. The "bug" is the feature.

Good PMs ship features. Great PMs ship trade-offs users don't realise they accepted.

Why India is harder than the US

Netflix peaks at ~15M concurrent globally for a tentpole. JioHotstar does 4× that, in one country, on mostly 4G, with users on devices ranging from a ₹6,000 Android Go phone to an Apple TV. The product team had to design for a network where the variance — not the average — is the enemy.

• Device fragmentation: 18,000+ distinct device models in the active install base.
• Network fragmentation: Jio fibre, Airtel 5G, BSNL 4G, public Wi-Fi — all in the same household.
• Behavioural concentration: 60M people press play within a 4-minute window. There is no smoothing.

Where the magic actually lives

• Multi-CDN with real-time switching. Akamai, Cloudfront, and Jio's own CDN run in parallel. The player switches CDN mid-stream based on packet loss — invisibly. If Akamai degrades in Pune at 8:47 PM, the player has moved to Jio CDN by 8:47:03.
• Edge pre-warming. 30 minutes before toss, every video segment of the pre-match show is pushed to all 3,500 ISP edge caches in India. Origin servers serve almost zero user traffic during peak.
• Adaptive Bitrate (ABR) with a regional bias. The default starting bitrate isn't fixed at 1080p. It's chosen based on the user's ISP, pincode, and historical RTT. A Jio fibre user in Bengaluru starts at 1080p. A BSNL 4G user in Bhagalpur starts at 360p. Both feel fast.

What looks like infra is actually a product call

• Default "Auto" quality, not "HD". One toggle protects 90% of users from themselves. Power users who pick 1080p get it; everyone else gets the bitrate their network can handle.
• Free tier, ads-funded. The 2023 decision to make IPL free wasn't just marketing — it spread load across a wider user base and let Jio negotiate better edge deals with ISPs. The business model is the infra strategy.
• Multi-audio without re-encoding. Hindi, Tamil, Telugu, Kannada, Bhojpuri commentary as separate audio tracks on the same video segment. Saves ~75% of storage and edge cache space vs separate streams.
• Latency-tier pricing. Premium subscribers get 5-second latency; free users get 30–45 seconds. This isn't a degradation — it's a deliberate buffer that lets the free-tier infra absorb spikes the premium tier can't.

Honest read on the failure modes

Buffering still happens. Where?

• Six-hits-in-an-over moments. When Kohli hits a six, 8M users scroll to social, drop the app to background, come back, and re-buffer. The team mitigates this with persistent buffer on background.
• Last-mile ISP saturation. When 90% of an apartment complex on the same ISP is watching at once, the bottleneck moves from CDN → ISP backhaul. Jio's response: native multi-cast to TV via Jio set-top box, which serves the building from one stream.
• App cold start under contention. Opening the app at 7:29 PM is much slower than at 7:31 PM. The product team has been A/B testing pre-loaded splash content to mask this.

The PM lesson

The team that built this didn't optimise for "no buffering." They optimised for the lowest perceived buffering across the widest possible variance of devices and networks. Different metric. Different product.

When you can't fix the hardest case, you redesign the experience so the hardest case looks acceptable. That's product, not engineering.

The thing nobody was complaining about, loudly

The original ride-start flow looked sensible: customer books, driver arrives, system sends a dynamic 6-digit OTP to the customer's phone, customer shows OTP to driver, driver enters it, ride starts.

What Rapido's product team saw in the data:

• 11% of rides had a delayed start because the SMS hadn't arrived.
• 3% of rides were cancelled outright after the driver had reached the pickup — purely because of OTP failures.
• Driver frustration was disproportionately high. Drivers blamed customers; customers blamed the network; both blamed Rapido.

The friction wasn't in the OTP. It was in the delivery channel.

"Why is the OTP travelling at all?"

The insight that broke the problem open was a question: the customer is already authenticated inside the app. The driver is already authenticated inside the app. Why does the OTP need to go through a third-party SMS gateway and a flaky cellular network?

The answer: it doesn't. The OTP can be a static, ride-specific 4-digit code generated by the backend and shown on the customer's app screen at the moment of pickup. The driver enters it in their app. Both ends are inside Rapido's own trust boundary.

Why this wasn't obvious to Uber and Ola

Both incumbents had considered it and rejected it for three reasons:

• "Static OTP is less secure." Technically true. Practically irrelevant — the security model is "the driver is at your pickup location and you are showing them a code." It doesn't need to be a one-time SMS-validated token. It needs to be a shared secret for 90 seconds.
• "Customers won't trust a screen-OTP." Untrue. Customers trusted UPI PINs on the same screen. Trust wasn't the issue — habit was.
• "SMS proves the customer's phone number is real." Already proved at signup. The OTP-at-ride was solving a problem that had been solved 18 months earlier.

Rapido shipped it because they were smaller and the cost of being wrong was lower. Once the data came back positive — completion up, support tickets down, cost down — the larger players had a forcing function.

What Rapido proved in 90 days

Indexed deltas, Rapido internal disclosures and ecosystem estimates.

The PM lesson

The most valuable product decisions are often subtractive. Rapido didn't add a feature — they removed an entire dependency (SMS) and a moving part (dynamic generation). The interface became simpler, the system became cheaper, and the customer noticed nothing.

If a product team is celebrating launches, count what they removed, not what they shipped. The best PMs are professional deletionists.