Designing Hotstar: Live Cricket for Tens of Millions at Once

Final night: everyone arrives at the toss

It's the World Cup final. Ganesh, a college student in Bihar, watches on a ₹7,000 phone over patchy mobile data. In Pune, the Kulkarni family has gathered in front of a 65-inch smart TV. At 1:30 pm, when the toss happens, tens of millions of people open CricStream in the same few minutes. (Ganesh, the Kulkarnis, CricStream, Ritu and every number here are made up for teaching.)

Ritu leads CricStream's live platform. She describes final night with a school sports day. At nine o'clock sharp, a thousand parents arrive at the same gate. They don't trickle in over an afternoon. The gate is small, and you can't build a new one while they queue. So the school:

• opens extra gates the night before,
• puts signs at the entrance,
• has a plan for a crush: if the crowd grows too big, the snack stall closes first, never the gate to the field.

Live sports streaming has exactly that shape. Everyone wants the same match at the same second, and they arrive in a synchronised wave. On-demand video can be prepared ahead and cached slowly. Live video can't: the picture is being produced now, and everyone wants the newest few seconds. A system that copes with 20 million people spread over a day may fail with 20 million arriving in twenty minutes.

This guide designs live video for a very large audience in the style of Hotstar, now part of JioHotstar. It is an original interview design, not the internal architecture. It leans on two public sources:

• A 2019 talk by Hotstar's engineers, which reports a peak of 25.3 million concurrent viewers.
• A 2025 summary of Hotstar's later engineering posts, which reports over 61 million concurrent users in 2023. The summary is secondary, so it's used for its stated facts and no more.

For on-demand video, see the YouTube guide and the Netflix guide.

In 30 seconds, as an architect would frame it: "Keep two paths apart. Video flows encoder → packager → origin → CDN, as segments and live playlists, with request coalescing so the origin sees each new segment once. Everything else goes through an API gateway, where shared data such as scores is cached at the edge for seconds, and personal requests (session, entitlement, licence) are protected. Every device gets a manifest for its class from one encrypted, package-once ladder. Capacity is provisioned ahead of the match schedule, in steps, not by reactive autoscaling. And a tested degradation ladder switches extras off, and retries are damped, so the P0 video path stays alive."

1. The rules and the pieces

Viewers open the app, sign in, choose a match and watch live at a quality that suits their connection. They also see scores, highlights and other extras around the video. A subscription or an ad-supported plan decides what they may watch.

Ads, payments and content production are separate systems. This guide covers what happens between the camera and millions of screens.

The API class is the important design choice. Deciding it once for each endpoint is what lets you protect the servers later (section 3).

Two paths, kept apart

flowchart TD
    C@{ icon: "algomi:svc-cube", label: "Camera feed", pos: "b", h: 52 }
    E@{ icon: "algomi:ext-device", label: "Live encoder", pos: "b", h: 52 }
    C --> E
    K@{ icon: "algomi:async-gear", label: "Packager: segments and playlist", pos: "b", h: 52 }
    E --> K
    O@{ icon: "algomi:ext-server", label: "Origin", pos: "b", h: 52 }
    K --> O
    D@{ icon: "algomi:sec-globe", label: "CDN", pos: "b", h: 52 }
    O --> D
    V@{ icon: "algomi:svc-cube", label: "Viewers", pos: "b", h: 52 }
    D --> V
    G@{ icon: "algomi:svc-api", label: "API gateway", pos: "b", h: 52 }
    V --> G
    X@{ icon: "algomi:sec-globe", label: "CDN cache for shared data", pos: "b", h: 52 }
    G --> X
    S@{ icon: "algomi:svc-cube", label: "Session and entitlement services", pos: "b", h: 52 }
    G --> S
    F@{ icon: "algomi:async-gear", label: "Feature flags: degradation level", pos: "b", h: 52 }
    G --> F

Reading the diagram. Read it as two separate pipes that meet only at the viewer.

• The video path (top, camera to viewers) moves segments almost entirely through the CDN.
• The API path (bottom, viewers to gateway) carries everything else: sign-in, entitlement, scores and screens.

Keeping them apart means a problem in the score API can never slow the video. Feature flags sit on the API side, because that's where the degradation level is read (section 5).

2. "40 million screens, live": the video path