Back to System design
Back-of-Envelope: Video Streaming Bandwidth
mediumStreaming estimates are the clearest example of arithmetic driving architecture: the egress number is so large that it eliminates most designs before you have drawn them.
ScalePoP count × per-PoP capacity ≥ egress; transcoding compute by title volume
StoragePB-scale catalog + per-PoP cache
Key Concepts
1
Bitrate times concurrency is the whole first step. Everything else — storage, transcoding, edge
placement — follows from the aggregate egress. Get this number early and say it out loud, because it is the
reason the answer involves CDN appliances rather than a bigger origin.
Bitrate times concurrency is the whole first step.
2
Concurrency is not the subscriber count. The chain is subscribers, then daily viewers, then simultaneous
viewers at peak. A service with 200 million subscribers might have 10 million watching at once in prime
time — a 5% concurrency that you should state as an assumption, because it is the number most likely to be
challenged.
Concurrency is not the subscriber count.
3
The 4K mix changes the answer more than the user count. 4K at 20 Mbps is four times 1080p at 5 Mbps, so
shifting 20% of an audience to 4K adds more egress than adding 50% more viewers. This is why streaming
services care so much about codec efficiency: AV1 delivering the same quality at 30% fewer bits is a direct
reduction in the largest cost in the business.
The 4K mix changes the answer more than the user count.
4
Storage is a catalogue problem and it is smaller than people expect. A full ladder of renditions for one
title is roughly 100 GB, so 100,000 titles is about 10 PB for a single copy — a large number, but nothing
next to 50 Tbps of egress. The interesting decision is not total storage, it is which slice sits at each
edge.
Storage is a catalogue problem and it is smaller than people expect.
5
Transcoding is a fixed cost per title, paid once. A two-hour film across ten renditions and three codecs
is 60 hours of encoded output, parallelised into segments so it completes in minutes. It is a batch problem
with a deadline, not a scaling problem.
Transcoding is a fixed cost per title, paid once.
6
What the interviewer is probing.
What the interviewer is probing.
7
1. "How do you estimate bandwidth for a streaming service?" Probing: the derivation. Stalls:
"A lot." Moves up: concurrent viewers times the bitrate per stream — so a million concurrent at 5
Mbps is about 5 Tbps of egress.
1. "How do you estimate bandwidth for a streaming service?"
8
2. "Why does that number push you to a CDN?" Probing: the architectural consequence. Stalls:
"Cost." Moves up: no origin serves that, and egress from one region would be ruinous — the CDN
moves bytes close to users and absorbs the fan-out.
2. "Why does that number push you to a CDN?"
9
3. "What does adaptive bitrate change in the estimate?" Probing: the depth. Stalls:
"Nothing." Moves up: the average bitrate is well below the maximum, since many viewers are served
lower renditions — estimating at peak quality overstates it.
3. "What does adaptive bitrate change in the estimate?"
10
4. "What storage estimate follows?" Probing: the companion. Stalls: "It is small." *Moves
up:* each title stored in several renditions, so the catalogue size multiplies by the number of
encodings you keep.
4. "What storage estimate follows?"
The estimate, step by step
Step 1 -- audience (stated assumptions)
Subscribers 200,000,000
Watch on a given day 40%
Peak concurrency, as a share of daily viewers 12%
Concurrent streams 200M x 0.40 x 0.12 = ~10,000,000 Step 2 -- bitrate mix
480p 1.5 Mbps 10%
1080p 5 Mbps 70%
4K 20 Mbps 20%
Weighted average
0.10x1.5 + 0.70x5 + 0.20x20 = 7.65 Mbps Step 3 -- aggregate egress
10M x 7.65 Mbps = 76.5 Tbps
All-1080p comparison 10M x 5 Mbps = 50 Tbps
-> the 20% 4K share adds 26 Tbps, more than half again. Step 4 -- serving capacity
Per appliance at 100 Gbps = 100 Gbps
Appliances needed 76.5 Tbps / 100 Gbps = ~765
With redundancy and uneven regional load = 1,000+ Step 5 -- storage
Renditions per title (all codecs) ~100 GB
Catalogue 100,000 titles = 10 PB
Edge site holds the head (~2,000 titles) = 200 TB Step 6 -- monthly transfer
76.5 Tbps at peak; assume average is 40% of peak
30.6 Tbps x 86,400 s x 30 days / 8 = ~9.9 EB/month
-- which is why transit cost, not compute, is the P&L line.What the numbers rule out
A single origin
76.5 Tbps cannot leave one datacentre. Even 100 Gbps uplinks
would need 765 of them, before redundancy.
-> content must be replicated to the edge. Generic public CDN alone, at this scale
Possible, but the economics push you further: appliances placed
INSIDE ISP networks mean the bytes never cross a paid transit
link. This is the difference between a large bill and an
impossible one. Transcoding on demand
Encoding at playback time would need a CPU farm sized to peak
concurrency. Pre-encoding once per title is a fixed cost paid
before release.
-> the ladder is built ahead of time, always. Serving one bitrate
A 20 Mbps stream is unusable on a 4G connection at the edge of
a cell. Multiple renditions plus client-side switching is not a
nicety; it is what makes mobile viewing work at all. Storing everything at every edge
10 PB per copy against ~200 TB of appliance storage means each
site holds the head of its own regional distribution, with a
regional cache behind it for the tail.