Menu
The New Stack·October 17, 2026

Scaling Live Sports Streaming to 32 Million Concurrent Viewers: Lessons from JioHotstar

This article details the engineering strategies and lessons learned by JioHotstar (now JioCinema) in successfully live-streaming the Indian Premier League (IPL) cricket finals to a record-breaking 32 million concurrent viewers. It highlights critical system design considerations for high-uncertainty events, focusing on capacity planning, identifying golden paths, rigorous testing methodologies, and managing latency budgets across distributed systems.

Read original on The New Stack

Architecting for Extreme Scale and Uncertainty

JioHotstar engineers adopted a proactive approach to handle the unpredictable nature and massive scale of live sports streaming. Their core strategy involved building and testing for roughly double the expected peak capacity, aiming for 50-75 million concurrent users when anticipating 32 million. This substantial headroom is crucial for absorbing sudden traffic spikes and preventing system overloads, ensuring a smooth user experience even under extreme load.

Identifying the Golden Path and Critical Dependencies

A fundamental principle was to designate video delivery as the "golden path," where failure is unacceptable. While CDNs handle the final video stream, critical bottlenecks often appear upstream, particularly in authentication and user login systems. The highest concurrency peaks are often observed on the first day of an event, as a large influx of new or infrequent users attempt to log in simultaneously. To mitigate this, they preemptively scale authentication systems and rigorously load test third-party partners (e.g., SMS providers), redirecting traffic instantly if latency SLAs are breached.

ℹ️

Sacrificing Non-Critical Systems for Core Experience

The article emphasizes that engineers should be prepared to sacrifice "every other system and component in the line" if necessary to ensure the integrity of the video delivery path. This highlights a critical trade-off: in extreme high-load scenarios, non-essential functionalities (like certain analytics or less critical features) might be temporarily degraded or disabled to protect the core user experience.

Rigorous Testing and Latency Budgeting

  • 200-Point Checklist: A comprehensive system audit covering databases (versions, maintenance windows), third-party dependencies, redundancy, and timeout configurations across all layers (load balancers, services, databases, CDNs). Many checkpoints originated from past incidents, ensuring continuous improvement.
  • Vertical Testing: Isolating and scaling individual systems, services, and partners (SMS, email, ad providers) to ensure each can handle expected load independently.
  • Multi-System Load Testing: Assessing how clusters of interdependent systems perform together, revealing issues that might not appear in isolated tests (e.g., fan-in problems where one system is called by multiple sources).
  • Full User-Like Simulation: Simulating actual user behavior on the mobile app/website to stress the entire system end-to-end, identifying bottlenecks and scaling issues that only manifest under realistic conditions.

Strict latency budgets are enforced: 10-15 ms for simple in-house O(1) lookups, 40-50 ms for complex in-house operations with multiple calls, and a very tight 5-10 ms circuit-breaking budget for unavoidable third-party calls in critical paths. This aggressive approach pushes teams to optimize, cache aggressively (e.g., component-level caching for personalized pages), and identify what can be handled asynchronously to maintain user-perceived latencies of 60-100 ms.

Key Principles for High-Uncertainty Events

  1. Set principles correctly and achieve org-wide alignment: This drives consistent decision-making before, during, and after the event.
  2. Challenge your systems and don't settle: Continuously optimize server-side latencies, aiming for sub-hundred-millisecond response times given modern computing power.
  3. Identify and solidify your critical path: Scrutinize all synchronous calls. Any non-P1 or P2 dependency should be moved out of the synchronous critical path, even if it requires re-architecting components or saying no to certain features.
live streamingscalabilityhigh concurrencyload testingperformance optimizationreliabilityauthenticationcdn

Comments

Loading comments...