Video streaming architecture.
Around ninety-nine percent of the bytes never touch your servers, which means most of this design is about preparing files so the CDN can do the work.
The components
Every row below is read from the graph that produced the diagram above, so the two cannot disagree.
| Component | Tier | Why it is there |
|---|---|---|
| Player | Client | Adaptive bitrate, picks a rendition |
| CDN | Edge | Serves ~99% of bytes |
| API gateway | Edge | Supporting component |
| Upload service | Application | Supporting component |
| Transcode farm | Application | One job per rendition, fan-out |
| Catalog | Application | Supporting component |
| DRM & licensing | Application | Supporting component |
| Job queue | Data | Supporting component |
| Raw store | Data | Mezzanine masters |
| Packaged store | Data | HLS and DASH segments |
| Postgres | Data | Supporting component |
Design decisions worth arguing about
A diagram shows what was chosen. It does not show what it cost, and that is usually the part that matters in a review or an interview.
Transcode once, serve many times
Transcoding on demand sounds efficient and is ruinous: it is expensive, slow, and repeated for every viewer. Producing every rendition on upload trades storage, which is cheap, for compute, which is not. The cost is upload-to-available latency measured in minutes rather than seconds, and a large multiplier on storage since every title exists at several bitrates.
One job per rendition, so failure is granular
Treating a whole video as one transcode job means a failure at ninety percent redoes everything, and one very long video occupies a worker for hours. Fanning out per rendition, and per segment for long content, makes each unit small, retryable and parallel. It costs an orchestration layer that knows when all the pieces of a title are done, which is more coordination than a single job needs.
Adaptive bitrate moves the decision to the client
The player measures its own throughput and picks a rendition, which handles varying networks far better than any server-side guess. The consequence is that you must produce and store a ladder of renditions whether or not anyone watches the lower ones, and that quality complaints become hard to diagnose because the server did not choose what was delivered.
DRM constrains everything downstream
Licensed content requires encrypted segments and a license server, which means the CDN can no longer serve fully anonymously, playback needs platform-specific DRM systems, and testing requires real devices. If the catalog does not need it, not having DRM removes a large amount of complexity. Once one title needs it, the whole delivery path is shaped by it.
How it changes with scale
Delivery scales with the CDN, which is someone else's problem and your largest bill. Transcoding scales with catalog growth rather than viewership and is bursty, which makes it a good fit for preemptible capacity. Storage grows monotonically and never shrinks, so lifecycle policies moving cold titles to cheaper tiers matter more over time than any compute optimisation.
Where it breaks first
A thundering herd on a new release. Everyone requests the same first segments within minutes, and until the CDN has them cached those requests all reach the origin. Pre-warming the edge before a scheduled release is the standard answer, and forgetting to do it is the standard incident.
Draw this yourself
Open the Diagram tab and describe the system. The agent emits a semantic graph rather than coordinates, so you can edit the components and the layout re-solves instead of drifting.
When the shape is right, Implement in code turns the canvas into a markdown specification, every component, every relationship and the notes, and starts a real turn in the Code tab with it.
Questions about this design
More templates
- URL Shortener System DesignThe canonical read-heavy system: roughly a hundred reads for every write, and a redirect that has to be fast enough that nobody notices it happened.
- Chat Application System DesignLong-lived connections change everything: the hard part is not storing messages, it is knowing which of your servers is holding the socket you need to write to.
- Payment System DesignThe only system on this list where being approximately right is indistinguishable from being wrong, and where the provider, not you, holds the truth.
- RAG Pipeline ArchitectureAlmost every RAG system that disappoints is failing at retrieval, not generation, and the architecture is what decides whether you can tell.