How does a video platform transcode uploads at scale?

It treats transcoding not as one job but as a directed acyclic graph (DAG) of small, mostly-independent tasks. The uploaded video is inspected, split into GOP-aligned segments (each a self-contained chunk that decodes on its own), and then every segment is encoded into every rung of a bitrate ladder in parallel across a fleet of stateless workers, while the audio track and thumbnails encode on their own lanes. A scheduler hands tasks to workers through queues, with segments living in temp storage between stages, and only once a resolution’s segments are all done does a package step stitch them and write the manifest. Facebook’s Streaming Video Engine is exactly this shape, reporting “a complicated set of DAGs averaging 153 video processing tasks per upload.” The payoff of the graph is both speed (serial minutes become parallel seconds) and fault isolation — a worker dying costs a single re-queued segment, not the whole video.

Why do clients upload video with pre-signed URLs instead of through the API?

Because routing hundreds of megabytes of pixels through your own servers makes them the bottleneck and the bandwidth bill for ingest. Instead, the API hands the client a pre-signed URL — a temporary, cryptographically-signed link that grants permission to write one specific object to storage, for one method, for a few minutes — and the client uploads the bytes straight to object storage with it. The metadata (title, creator, the fact a video exists) goes through the API to the database on a separate fast lane, so the creator sees progress instantly while the heavy content takes the direct path. The upload is also cut along GOP boundaries and sent as parallel segments, so a dropped connection only retries the unfinished pieces — and that same split is the one the transcoder later parallelizes over.

What is adaptive bitrate streaming (ABR)?

It is how a player keeps video smooth as the network changes second to second. During transcoding the platform produces not one output but a bitrate ladder — a set of renditions from a tiny 240p stream up to 4K — and serves the video in short segments (a few seconds each) that exist at every rung. Before each segment, the player measures how fast the last one arrived and picks the highest rung it can afford, leaving a safety margin so a brief dip re-picks a lower rung instead of stalling. The two dominant protocols, Apple’s HLS and the open DASH, both work this way: a manifest file lists the available renditions and their segment URLs, and the player does the choosing. The server just offers the ladder. Netflix even tailors the rungs per title, since “each title should receive a unique bitrate ladder, tailored to its specific complexity characteristics.”

Why does CDN delivery dominate the cost of a video platform?

Because delivering bytes at play time dwarfs storing them at rest. A mid-size platform of 5 million daily users watching 5 videos a day at 300 MB each moves 7.5 petabytes of egress every single day; at roughly $0.02 per gigabyte of CDN egress that is about $150,000 a day, north of $50M a year — while the storage of the originals is rounding error beside it. A content delivery network (a fleet of caches near viewers) makes the bytes local and fast, but it does not make them free: you still pay egress per gigabyte delivered. That single number is why the design obsesses over shrinking each stream with smart per-title encoding, over serving from cache instead of origin, and over not paying to push cold videos everywhere.

How does the long tail lower a video platform’s delivery cost?

Viewing is wildly uneven: a tiny fraction of videos gets the overwhelming majority of plays, and a vast cold catalog is barely touched. So you don’t cache everything everywhere — you cache the hot set at the edge, where a small slice of the catalog serves most of the plays, and serve the cold tail from central origin storage only on a cache miss. Because those cold videos are rarely watched, the expensive origin bandwidth stays small even though it backs a huge catalog. The same skew justifies lazy transcoding: a video nobody watches never needs its full bitrate ladder built on upload — encode it on the first request and cache the result. The hot set gets the full parallel-DAG treatment at ingest; the cold tail is transcoded and served only when someone actually shows up.

Design a Video Platform

Someone uploads a 4K clip; seconds later millions can stream it on a train, a laptop, a TV — and the bill to deliver it dwarfs the bill to store it. Built from zero: a commit-first envelope on the CDN egress bill (5M users × 5 plays × 300 MB is 7.5 PB a day, and the number should scare you), why one server melts, the two-lane upload with pre-signed URLs writing straight to storage and GOP-aligned resumable segments, the heart — transcoding as a DAG of tasks where every segment × resolution encodes in parallel and a dead worker costs one segment not one video, adaptive bitrate over a per-title ladder with the player choosing rung by rung, CDN economics and the long tail (cache the hot set, serve the cold tail from origin, lazily transcode what nobody watches) — then the failure sweep whose sharpest box is a poison video that turns your own idempotent retry into a fleet-killer.

System design · Systems. The source ↗

A free, interactive, animated visual explainer of Design a Video Platform — built to be understood, not skimmed.

Questions

How does a video platform transcode uploads at scale?: It treats transcoding not as one job but as a directed acyclic graph (DAG) of small, mostly-independent tasks. The uploaded video is inspected, split into GOP-aligned segments (each a self-contained chunk that decodes on its own), and then every segment is encoded into every rung of a bitrate ladder in parallel across a fleet of stateless workers, while the audio track and thumbnails encode on their own lanes. A scheduler hands tasks to workers through queues, with segments living in temp storage between stages, and only once a resolution’s segments are all done does a package step stitch them and write the manifest. Facebook’s Streaming Video Engine is exactly this shape, reporting “a complicated set of DAGs averaging 153 video processing tasks per upload.” The payoff of the graph is both speed (serial minutes become parallel seconds) and fault isolation — a worker dying costs a single re-queued segment, not the whole video.
Why do clients upload video with pre-signed URLs instead of through the API?: Because routing hundreds of megabytes of pixels through your own servers makes them the bottleneck and the bandwidth bill for ingest. Instead, the API hands the client a pre-signed URL — a temporary, cryptographically-signed link that grants permission to write one specific object to storage, for one method, for a few minutes — and the client uploads the bytes straight to object storage with it. The metadata (title, creator, the fact a video exists) goes through the API to the database on a separate fast lane, so the creator sees progress instantly while the heavy content takes the direct path. The upload is also cut along GOP boundaries and sent as parallel segments, so a dropped connection only retries the unfinished pieces — and that same split is the one the transcoder later parallelizes over.
What is adaptive bitrate streaming (ABR)?: It is how a player keeps video smooth as the network changes second to second. During transcoding the platform produces not one output but a bitrate ladder — a set of renditions from a tiny 240p stream up to 4K — and serves the video in short segments (a few seconds each) that exist at every rung. Before each segment, the player measures how fast the last one arrived and picks the highest rung it can afford, leaving a safety margin so a brief dip re-picks a lower rung instead of stalling. The two dominant protocols, Apple’s HLS and the open DASH, both work this way: a manifest file lists the available renditions and their segment URLs, and the player does the choosing. The server just offers the ladder. Netflix even tailors the rungs per title, since “each title should receive a unique bitrate ladder, tailored to its specific complexity characteristics.”
Why does CDN delivery dominate the cost of a video platform?: Because delivering bytes at play time dwarfs storing them at rest. A mid-size platform of 5 million daily users watching 5 videos a day at 300 MB each moves 7.5 petabytes of egress every single day; at roughly $0.02 per gigabyte of CDN egress that is about $150,000 a day, north of $50M a year — while the storage of the originals is rounding error beside it. A content delivery network (a fleet of caches near viewers) makes the bytes local and fast, but it does not make them free: you still pay egress per gigabyte delivered. That single number is why the design obsesses over shrinking each stream with smart per-title encoding, over serving from cache instead of origin, and over not paying to push cold videos everywhere.
How does the long tail lower a video platform’s delivery cost?: Viewing is wildly uneven: a tiny fraction of videos gets the overwhelming majority of plays, and a vast cold catalog is barely touched. So you don’t cache everything everywhere — you cache the hot set at the edge, where a small slice of the catalog serves most of the plays, and serve the cold tail from central origin storage only on a cache miss. Because those cold videos are rarely watched, the expensive origin bandwidth stays small even though it backs a huge catalog. The same skew justifies lazy transcoding: a video nobody watches never needs its full bitrate ladder built on upload — encode it on the first request and cache the result. The hot set gets the full parallel-DAG treatment at ingest; the cold tail is transcoded and served only when someone actually shows up.

Design a Video Platform

Questions

Related explainers