Hotstar reported a peak of 25.3 million concurrent viewers for the India-New Zealand World Cup semi-final on 10 July 2019 and about 59 million for the 2023 World Cup final; JioCinema reported roughly 62 crore reach across IPL 2024. A product lead asks you to cost a free ad-funded stream at that concurrency. What did these platforms have to engineer, and where would copying it be a mistake?

The situation they were in

Peak concurrency, not cumulative reach, sets the capacity bill. The two must never be mixed: 62 crore reach is a season-long count of distinct viewers and tells you nothing about the worst second, while 25.3 million concurrent is a number you must be able to serve simultaneously.

Convert the concurrency to bandwidth, because that is where the money is:

• At an average delivered 2.5 Mbps: 25.3e6 x 2.5e6 = 63 Tbps
• At 0.8 Mbps (a mobile-heavy ladder): 20 Tbps
• At 6 Mbps (a television-first audience): 152 Tbps

For scale, the highest whole-platform peaks publicly announced by the largest commercial delivery networks were in the low hundreds of Tbps as of the early 2020s - all customers, all traffic. One cricket match at a television-grade bitrate is the same order of magnitude as that figure. The bitrate assumption alone swings the answer 7.5x, which is more than every other uncertainty combined.

What they had to choose

The average delivered bitrate is the design variable, not a consequence. The arithmetic forces it. Per viewer-hour at 2.5 Mbps: 2.5e6 x 3600 / 8 = 1.125 GB. At a delivery price of P dollars per GB, delivery costs 1.125 x P per viewer-hour.

The ad side: eight 30-second impressions in a viewing hour at a CPM of C yields 8 x C / 1000 = 0.008 x C. Break-even requires C >= 141 x P. At P = \(0.005/GB you need a **\)0.70 CPM; at a television bitrate of 6 Mbps the same CPM requirement becomes $1.70**.

That is why these services engineer the ladder downward and cap resolution during peaks rather than buying capacity. Dropping the average from 2.5 to 1.5 Mbps cuts the bill 40% and moves break-even CPM from $0.70 to $0.42 - a larger lever than any infrastructure negotiation, and available in seconds during the match.

What it cost them

Everything downstream of the bitrate decision: a transcode ladder with aggressive low rungs, client logic that accepts a lower rung under congestion without buffering, and a willingness to serve a visibly worse picture at the moment most viewers are watching. The platform optimises for "nobody stalls" over "everybody gets 1080p", which is a product decision dressed as an engineering one, and it is only correct because the revenue per viewer-hour is fixed and small.

Where copying it would be a mistake, and when this is the wrong model

If revenue per viewer-hour does not scale with watch time, the whole calculation inverts. A subscription service earns the same monthly fee whether a user watches 2 hours or 40, so marginal watch time is pure cost and the lever is not the bitrate but the ratio of heavy users to light ones. Capping bitrate there attacks the perceived value you were paid for in advance.

If the audience is television-first, the low rungs are unusable. A 0.8 Mbps rung that works on a phone looks broken on a 65-inch screen, so the band the arithmetic lets you choose from is narrower and the break-even CPM is higher - which means an ad-funded model may simply not close.

And if your peak is a tenth of this, none of it applies. At 2.5 million concurrent you are inside the normal envelope of a commercial delivery network, the engineering effort belongs elsewhere, and copying a bitrate-capping architecture buys a worse product for no saving that matters.