JioHotstar live IPL
Not climbed yetModel answer
The broadcast feed goes to an encoder, which compresses it into several qualities at once, say from 240p up to 1080p.
A packager cuts each quality into segments a few seconds long and writes a playlist listing them, in HLS (
.m3u8) or DASH (.mpd) format. For live video the playlist keeps growing as new segments appear.Segments and playlists sit on an origin server, and a CDN copies them to edge servers near the viewers. The phone downloads the playlist, then the segments one after another, over ordinary HTTP.
The player uses adaptive bitrate: it measures how fast segments arrive and switches quality between segments, so a weak network gets a blurrier picture instead of buffering. The price of segments is delay: the stream runs several seconds behind the stadium.
Model answer
With 4-second segments, each viewer fetches a segment every 4 seconds: 50 million / 4 = 12.5 million requests a second, plus about as many playlist refreshes. At an average of 2 Mbps each, that is 100 Tbps of video. No single data centre serves that; it comes from many CDN edge locations, many of them inside internet providers' networks.
What saves you: everyone watching the same quality asks for the same file. An edge server fetches each segment once and serves it from memory to everyone nearby, and request collapsing makes the thousands who ask in the same instant wait for that one fetch.
An origin shield, a middle layer of caches between the edges and the origin, means the origin sees a handful of requests per segment and quality, however many people watch. Segments never change, so they are cached for long; playlists change every few seconds, so their TTL is short.
Use more than one CDN, with steering (by DNS or in the player) that shifts traffic based on measured performance. That adds capacity, and one CDN's outage does not become yours.
Model answer
Video is on the CDN; the APIs are not. A big moment brings millions back into the app at once. Say 10 million open it within two minutes: about 83,000 opens a second, and at 5 API calls each, over 400,000 API requests a second, against servers sized for a normal evening.
- Pre-scale for moments you can see coming: the toss, the innings break, the last overs. Autoscaling takes minutes to add servers, and the spike is over by then.
- Cache API responses at the CDN. The home page and scorecard are the same for everyone (or per language), so a TTL of a few seconds turns millions of calls into a handful.
- Graceful degradation: switches that turn off non-essential features (recommendations, comments, watch-history writes) under load, so login and playback survive.
- Jittered retries in the app: exponential backoff with randomness, so a struggling API is not hit again by millions of phones retrying in step.
Keep people signed in with long-lived sessions too, so a peak does not mean millions of fresh logins at the same moment.
Model answer
The score can be pushed or polled. Push needs a tier of WebSocket servers (at 100,000 connections each, 500 servers) plus pub/sub to send each update to all of them. Polling is simpler: a small JSON file on the CDN with a 2-second TTL, fetched every 5 seconds with jitter, is 10 million requests a second at the edges and almost none at the origin. For a score that changes once a ball, polling is usually enough.
Do not let the score beat the video. The stream runs several seconds behind, and a score that shows the wicket before the picture does spoils it. Delay score updates by about the stream's delay.
Watching now: each player sends a heartbeat, say every 30 seconds, which for 50 million is 1.7 million a second. Sample instead: 1% of players send and you multiply by 100, accurate enough for a number shown rounded. To count distinct users, a HyperLogLog (Redis
PFADDandPFCOUNT) estimates within about 1% using 12 KB, and per-server counts merge.The rule under both: never query a database per viewer. Work out each number once every few seconds and serve the result from cache to everyone.
