200
Tbps of video at the evening peak
Assume a billion hours watched a day: 41.7M streams at once at ≈ 2.5 Mbps. No data centre serves that; bytes come from caches inside ISPs.
A 4.4-hour upload, and the signal drops
Bad: One big POST
Restart from byte zero. At a drop an hour, 1 in 80 finishes.
Good: 16 MiB parts
Parallel, straight to object storage. Resend one part, ≈ 13 s.
A 10-minute upload becomes 90 small encode tasks
15 chunks of 40 s × 6 rungs, all in parallel. A crash reruns one task, and 360p jumps the queue: playable in about a minute.
3 EB a year: renditions are earned
- Every upload: an H.264 ladder, never upscaled
- Past a few hundred views: add VP9 or AV1
- Six months unwatched: shrink to 360p
- Keep the original forever, on cold storage
Your train enters a tunnel. Throughput falls from 8 to 2 Mbps.
The trick
The player picks each 4 s segment’s rung from throughput and buffer. 19 s of buffer lets it step down, never stall.
3%
of peak bytes reach the origin
Caches inside ISPs serve the head (assume 85% hits). Regional shields catch 80% of the rest and coalesce misses. The origin sees 6 Tbps, almost all long tail.
Why a viral video’s view counter looks stuck
Views are events in a log. A fast path shows a rough count within a minute; hours later a verified, de-duplicated, fraud-filtered count replaces it.
Remember
Upload in resumable parts, encode chunk × rung in parallel, stream short segments from caches inside ISPs. Renditions are earned; view counts are fast first, verified later.