Design video upload and streaming
Five million uploads a day and a billion views. Transcode every video once into short segments at five qualities, put the bytes in an object store, and let a cdn serve them; the rest of the round is about what the cdn misses.
The round this design follows
Why cut every video into 4-second segments?
Segments do three jobs at once. The player can switch quality at every segment boundary, so a phone that loses signal drops to a lower rendition within four seconds instead of stalling. The cdn caches small immutable files, which it does well, and a seek fetches only the segments it needs. And the transcoder can work on every segment in parallel, which turns 750 seconds of serial work per video into about 2 seconds of wall time when enough workers are free.
What does the cdn hit rate actually buy?
At the peak viewers pull 1.3 TB/s of video. With 95 in 100 segment requests served at the edge, the origin sees 65.1 GB/s, a twentieth. Every point of hit rate is 13 GB/s at the origin, so the hit rate is the number to protect: long cache lifetimes on immutable segment paths, no per-viewer tokens in the cache key, and an origin shield between the edges and the store.
Why store video in an object store and not a database?
The bytes and the facts about them have opposite shapes. Segments are large, written once, read many times and never updated, which is what an object store is built for, at a fraction of a database's price per byte. The facts (which renditions exist, which segments landed, who owns the video, whether it is ready) are small rows that need transactions and indexes, so they live in a relational store. The manifest service joins the two by reading rows and handing out object paths.
What breaks first when a lot of people watch one video?
Not the cdn: a popular video is exactly what a cache is good at. The danger is a video published minutes ago, before any edge holds it, when every edge misses on the same segments at once and all of them land on the one store node under that video's key prefix. An origin shield, one cache tier between the edges and the store that merges identical misses into one fetch, turns that burst into one read per segment.
How many transcode workers does this need?
Each video is 300 seconds long and needs five renditions at twice real time, so 750 worker-seconds. Five million videos a day at the evening peak is about 86.8 thousand workers busy at once. The queue between upload and transcode means the workers can be cheaper spare capacity: a job waits a little longer at the peak, and nobody watching is affected.