Design Interviews · lesson 5 of 15 · about 30 min
A video service end to end: how much it stores and sends, how one upload becomes many renditions in minutes, how the player adapts to a bad network, how big uploads survive failures, how caches keep the origin alive, and what happens when everyone presses play at once. Tap any for a plain-language card.
Bytes in, bytes out
The ratio is what matters: a video is uploaded once but watched many times, so egress dwarfs ingest, and the storage bill is dominated by the number of renditions you keep. Estimate both, with inputs you can change. The bitrate ladder used here is illustrative: 300 kbps (240p) up to 6 Mbps (1080p).
500 hours of video a minute kept at 5 renditions is about 3.7 PB of new storage a day and 6.8 EB over 5 years. 50 million simultaneous viewers at 3 Mbps is 150 Tbps of delivery.
500 hours uploaded a minute, kept at 5 renditions, is 3.7 PB of new storage a day. 50 million viewers at 3.0 Mbps need 150 Tbps of delivery, which no single data centre can do: it must come from caches near the viewers.
Arithmetic with an illustrative ladder (300, 700, 1500, 3000, 6000 kbps). Storage ignores replication, thumbnails and the originals; real services keep fewer renditions for rarely watched videos.
Hours of video, minutes of waiting
Wall-clock time then depends on how many workers you have rather than how long the video is: roughly (jobs ÷ workers) × time per chunk, plus the fixed cost of splitting, stitching and publishing. Too-small chunks waste time on overhead and hurt compression efficiency; too-large chunks limit the parallelism. Failed jobs are simply retried, since each chunk is independent and the job is .
A 60-minute video at 2× real time and 5 renditions takes 2.5 hours on one worker. Cut into 10-second chunks and spread over 500 workers it is ready in about 50 seconds including a 30 s stitch.
A 60-minute video becomes 1,800 independent jobs (360 chunks × 5 renditions). With 500 workers it is live after about 50 s; one worker would need 694444.4 h. The CPU work, 2.5 h, is identical: parallelism buys latency, not efficiency.
Arithmetic: wall = ceil(jobs ÷ workers) × chunk length ÷ speed + fixed overhead. Ignores queueing, uneven chunk difficulty and startup time of workers.
The player chooses, every four seconds
The player is trading three things: quality (average bitrate), smoothness (switches) and, above all, rebuffering, which viewers hate most. A fixed high bitrate on a fluctuating link stalls constantly. The server stays dumb: static files from a , which is why this scales. Compare the policies on the same simulated network.
On a 4 Mbps link that fluctuates, a fixed 1080p (6 Mbps) stream spends 38% of the time stalled. A throughput-based player never stalls at 2.8 Mbps average; a buffer-based player stalls 0.2% at 3.7 Mbps.
Buffer-based on an average 4.0 Mbps link (fluctuation 0.3): 1 seconds frozen in a 10-minute viewing (0.2%), average quality 3.7 Mbps, 50 quality switches.
Seeded simulation: 4-second segments, a 30-second buffer cap, a log-normal AR(1) network. The throughput player uses 80% of a smoothed estimate; the buffer player maps buffer level to rung.
Uploading from a moving train
Chunks go straight to through (the server hands out permission, not bandwidth), and the object is assembled when all chunks are in. Smaller chunks lose less per failure but add per-request overhead; a few megabytes is typical. A checksum per chunk catches corruption. The same protocol (tus, Google's resumable upload) is what lets you pause and continue overnight.
2 GB with a 0.5% chance of failure per megabyte: a whole-file retry succeeds once in about 22,600 attempts. With 8 MB chunks you send about 2.1 GB in total.
A 2 GB file with a 0.5% failure chance per megabyte succeeds in one go with probability 4.4e-5. Restarting from zero would send about 45.2 TB in total; 8 MB resumable chunks send about 2.1 GB.
Probability the whole file survives = (1 − p)^megabytes. Whole-file expected data ≈ size ÷ that probability (counting failed attempts in full, an upper bound); resumable ≈ size ÷ (1 − p)^chunk.
Almost nothing reaches the origin
That is why services also pre-position expected hits near viewers (a popular show can be pushed to caches overnight), place caches inside ISP networks to avoid paying for transit, and tune what each tier keeps. This simulation sends Zipf-popular requests through an LRU edge cache and an LRU regional cache. Make the traffic flatter (a longer tail) and watch the origin share climb.
With popularity skew 0.9, an edge holding 2% of the catalogue and a regional tier holding 10%: the edge serves 36% of requests, the region 20% and the origin 44%. At 150 Tbps that is 66 Tbps at the origin, still far too much: real systems cache a much larger share.
With skew 0.9, edge caches holding 2% and regional caches 10% of the catalogue serve 36% and 20% of requests. 44% reach the origin: 65.7 Tbps of the 150 Tbps delivered.
Seeded simulation of 30,000 requests over 20,000 videos through two LRU tiers (cold start included, so steady-state hit rates are somewhat higher). Real catalogues are millions of titles with strong time-of-day and release-day effects.
Pick the technique
Each problem has one technique that fits best. Each answer is worth 20 XP.
Match the symptom: slow encodes, frozen playback, failed uploads, or an origin flattened by a simultaneous miss?
A one-hour upload takes three hours to become watchable.
Tip: press 1 to 4 to answer, Enter for the next one.
Who lives by this
Published facts about large video delivery.
CDN appliances in ISP networks
Netflix built its own CDN, Open Connect, placing cache appliances inside internet providers' networks and filling them with popular titles during off-peak hours, so most streams are served from inside the viewer's own provider.
tailoring the ladder
Netflix described analysing each title to choose its own bitrate ladder, since an animated show needs far fewer bits than a grainy action film for the same visual quality, saving bandwidth without hurting picture.
segmented adaptive streaming
Apple's HLS and the MPEG-DASH standard both split video into short segments listed in a manifest at several bitrates, letting the player pick, and letting plain HTTP servers and CDNs carry the traffic.
ISP-hosted YouTube caches
Google offers internet providers cache servers installed inside their networks to serve popular YouTube and other Google content locally, reducing transit traffic and improving playback for their customers.
Interview angle
Six questions, each worth 20 XP. Strong answers separate ingest from delivery and explain the CDN's role.
Say what is stored, how it is made, how it is delivered and what protects the origin.
Which is larger, ingest or delivery bandwidth?
Tip: press 1 to 3 to answer, Enter for the next one.
Break it
The cures are layered. Request coalescing: an edge that is already fetching a segment holds the other requests for it and answers them all from the single response, so each edge asks the origin once. An origin shield: a mid-tier cache that edges ask first, so the origin sees one request per segment in total. Pre-warming caches before a scheduled event and slightly delaying the live edge also help. Compare the modes.
5 million viewers on 200 edges against an origin that can answer 20,000 requests a second: without coalescing it sees 5,000,000 requests for one segment (250× overload); with edge coalescing 200; with a shield 1.
5M viewers all missing at once send 5M requests to an origin that can answer 20,000 a second: 250× overload, for one segment of identical bytes.
Arithmetic for one simultaneously requested uncached segment. Real traffic arrives over a few seconds, and each following segment repeats the pattern every four seconds, which is why coalescing must be built in.