Streaming a cricket final to tens of millions of concurrent viewers is not Netflix with a bigger cache. Live has no pre-encoded catalogue, no head start, and an audience that arrives in a single spike when a wicket falls.
Indian streaming platforms have carried concurrency records that dwarf anything in on-demand video — peaks in the tens of millions of simultaneous viewers for a single cricket match. The interesting part is not the absolute number. It is that on-demand traffic is smooth and predictable while live traffic is a step function.
Primary takeaway: every viewer converging on the same segment is actually the one thing working in your favour — it makes the workload almost perfectly cacheable. The design problem is getting that segment to every edge before the audience asks for it.
camera → contribution feed (single high-bitrate source)
→ transcoder fans out to a bitrate ladder
→ packager cuts fixed-duration segments + manifest
→ origin → multi-CDN → edge
→ player fetches manifest, then segments, on a loop
One source becomes many renditions — 144p through 1080p and beyond. On Indian mobile networks the lower rungs carry a very large share of viewers, so the ladder is weighted downward rather than treating 144p as a fallback nobody uses.
Short segments cut latency but multiply request volume and manifest churn. Longer segments cache beautifully and cost you seconds of delay — which viewers notice when a neighbour celebrates a six first.
Encoding many renditions in real time cannot fall behind even momentarily, because there is no opportunity to catch up on a live feed. That pipeline is provisioned for the peak ladder and run redundantly — usually two independent chains, so a failure in one does not interrupt the broadcast.
The defining event is not steady-state load. It is a million people opening the app inside a few seconds because a wicket fell, a super over started, or the match went to the last ball. Every one of them needs a manifest, an authentication check and a first segment at the same instant.
A spike that peaks in ten seconds is over before a new instance passes a health check. Capacity is provisioned against the match schedule, not against current load, and edge caches are primed with the opening segments before the toss.
A million requests for the same segment must become one request to origin. Request coalescing at the edge is the difference between a cacheable workload and an origin meltdown — and it works here precisely because everyone wants the same bytes.
Players refreshing a manifest on a fixed interval will synchronise into a standing wave of traffic. A small random jitter per client spreads that load flat, and costs nothing.
Under genuine overload the right move is to cap the ladder — push everyone down a rung or two. A viewer watching at 480p is still watching; a viewer shown an error is lost, and will retry immediately, adding load exactly when there is none to spare.
Interview angle: graceful degradation is where this question separates candidates. Almost everyone describes a CDN. Far fewer say what the system gives up first, and why quality is the right thing to sacrifice before availability.
At this concurrency the traffic exceeds what one provider will comfortably carry in one country. Traffic is split across providers and steered in real time on measured performance per region and per ISP, not on a static weighting.
Players report rebuffer ratio, startup time and error rate continuously. Those signals, aggregated per region, decide which CDN the next cohort is sent to — the control loop that makes multi-CDN useful rather than merely redundant.
Segmented streaming inherently trails the live event by a few segments. Cutting that to near real time requires chunked delivery and low-latency modes, which trade away some of the cacheability that makes this scale possible in the first place. Being able to state that trade-off — and that a cricket audience notices delay because of social media and the neighbours — is a strong signal in an interview.
Every viewer needs a subscription check, but the check cannot sit on the segment path. Issue a short-lived signed token at session start and let the edge validate it locally — no call back to an auth service per segment.
Live score, commentary and chat are low-volume, high-fanout — a fundamentally different shape from video. They belong on their own pub/sub path, so that a chat outage never touches the stream.
Yes. Design Hotstar, design a live streaming platform, design JioCinema, design YouTube Live and “how do you stream IPL to 50 million people” are the same question. Interviewers in India usually reach for the cricket framing because the concurrency numbers are concrete and public.
It is a different question from designing Netflix or YouTube on-demand. Those are catalogue problems — encode once, cache widely, personalise recommendations. This is a real-time problem where the content does not exist until moments before it is requested, and where the audience arrives all at once.