Design live cricket streaming for 25M+ viewers (JioHotstar)

Autoscaling reacts in minutes; cricket traffic jumps by millions in under a minute, and new instances also need warm caches and connection pools. So the platform scales ahead of time. Start from a forecast per match (teams, stage, day of week, time) built from past matches; India vs Pakistan or a final gets the top tier. Provision API, entitlement and ad services for 1.5-2x the forecast peak about an hour before the toss, pre-warm caches (config, match page, entitlement caches), and raise CDN commitments with each provider days in advance, since CDN and ISP capacity cannot be bought on the spot. Validate with load tests that simulate the real traffic shape, including surges and mass reconnects, not just a steady rate; Hotstar has spoken publicly about running large synthetic load tests before big tournaments. Know your limits per component in advance, including hidden ones: database connection limits, OTP SMS provider throughput, cloud account quotas for instances and load balancers, and NAT or IP limits. Scale down only after the match, slowly.

At 50M users something will be short of capacity, so decide in advance what to switch off. Define levels and rehearse them. Level 1: turn off personalised recommendations, watch-history writes and non-essential widgets; serve one static match page from CDN. Level 2: stop showing live viewer counts per user, increase heartbeat interval from 60 s to 5 minutes, pause profile and settings updates. Level 3: cap maximum bitrate (e.g. 720p for subscribers, 480p for free users) to fit within total CDN capacity; this is the main lever because egress is the scarcest resource. Level 4: put new logins in a waiting queue and extend validity of existing tokens so logged-in users are never kicked out. Levels are feature flags delivered through the CDN-cached config endpoint, so changing them does not need the struggling API tier. The principle: protect the video for people already watching above everything else. A client that cannot reach a non-essential API must fail silently, not show an error screen.

No single CDN has 50-70 Tbps of spare capacity in India on a match night, and Indian traffic is concentrated on a few large mobile ISPs. So the stream is published to several CDNs from redundant origins in two cloud regions, each with its own encoder and packager fed by two independent paths from the stadium (with identical segment numbering so players can switch). The playback service steers sessions by weights per (ISP, region, CDN) from real-time QoE data, and playlists contain alternate CDN URLs so players can switch mid-stream on errors. Request collapsing at shields means each segment is fetched from origin only a few times per CDN. The ladder is tuned for mobile: most viewers watch on phones where 480p-720p looks good, so a good 720p at ~1.5-2 Mbps matters more than 4K. Multi-language commentary is delivered as separate audio renditions sharing the same video, which saves bandwidth and lets users switch language without rebuffering; the bitrate cap is applied per user tier through the playback token and player config.

Two features hit everyone at exactly the same moment. Ads: per-user ad decisions at an over break would be millions of requests per second to the ad server in a few seconds, plus per-user stitched playlists that the CDN cannot cache. Instead, segment users into a manageable number of cohorts (language, region/city tier, device, subscriber status, sometimes broad interest), decide ad pods per cohort before the break, and serve cohort-specific playlist variants that the CDN caches like any other content. Impression tracking is batched and delayed so it does not compete with the stream. Scorecard: keeping 25M WebSockets open just to push a score every 30 seconds is expensive and fragile under reconnect storms. Publish the scorecard as a small JSON file to the CDN after each ball with a short cache TTL (2-5 s), and let clients poll it with jitter, or embed score data in the video stream's timed metadata. Polling a cached file scales with the CDN, not with your servers. Spoilers matter: because video runs ~20 s behind live, the app should delay the scorecard to match the player's position.

Low-latency modes with 1-2 s buffers rebuffer more on congested 4G and cause more retries during surges. For a mass audience, a 15-30 s behind-live buffer gives smoother playback; the cost is spoilers from TV or social media, which you reduce by syncing the scorecard and notifications with the player position.

Per-user targeting earns more per impression but cannot be served to 25M people at once from cache. Cohort pods give most of the value with CDN-cacheable playlists. Per-user decisions can still be used at smaller events.

WebSockets give instant updates but cost millions of persistent connections and are brittle under reconnect storms. Polling a CDN-cached file every few seconds is cheaper, scales with the CDN and fails gracefully.

Capping at 720p or 480p during peaks reduces quality for some viewers but prevents widespread rebuffering when total CDN capacity is short. Make the cap tier-aware and dynamic, not a blanket permanent setting.

If the app or a CDN glitches for 10 s, millions reconnect at once and the reconnect storm can be bigger than the original peak. Clients use exponential backoff with full jitter, tokens stay valid so reconnects skip login, and the playback API is cheap and cache-backed.

New sign-ups before a big match can exceed SMS provider limits. Push sign-up campaigns days earlier, use multiple SMS providers and WhatsApp OTP, queue requests with a visible wait, and never force existing users to log in again during a match.

Cloud quotas, load balancer warm-up, NAT port exhaustion and database connections fail before CPU does. Find them in load tests and raise them in advance.

Two encoder/packager chains run in two regions with aligned segments. CDNs or players fail over to the secondary origin; viewers see at most a short stall.

Real-time QoE dashboards detect it in about a minute; steering shifts new sessions and players switch to alternate URLs. If remaining capacity is not enough, the bitrate cap is lowered.

Playback tokens are signed and carry plan information, so already-logged-in users keep watching even if the database is slow. New logins are queued; the failure mode is 'wait', not 'kicked out'.

The packager falls back to a default slate or a house promo during the break. Ad failure must never break the video.