How Would You Design a Video Streaming Platform Like Netflix?
Learn how to design Netflix: multi-bitrate transcoding, adaptive streaming, CDN edge caching, and separating video from metadata.
Expected Interview Answer
A Netflix-style streaming platform is built around an asynchronous transcoding pipeline that converts each uploaded video into multiple bitrate renditions and chunks (for adaptive bitrate streaming), a global CDN that caches and serves those chunks close to viewers, and a metadata/recommendation service that stays entirely separate from the heavy video delivery path.
When a new title is ingested, a transcoding pipeline splits it into short chunks (a few seconds each) and encodes each chunk at multiple bitrates and resolutions, producing a manifest file (like HLS or DASH) that lists every available rendition. The client’s adaptive bitrate (ABR) player continuously measures its own network throughput and buffer health, then requests the next chunk at whichever bitrate best fits current conditions — this is what lets playback degrade gracefully on a bad connection instead of buffering or crashing. Video chunks are cached aggressively at CDN edge nodes (and Netflix famously runs its own CDN appliances inside ISPs) so playback almost never needs to reach an origin data center. Metadata — titles, descriptions, thumbnails, viewing history, and recommendations — lives in a completely separate, much smaller service, since browsing the catalog and streaming video have wildly different scaling and latency profiles.
- Chunk-based multi-bitrate encoding lets adaptive streaming adjust smoothly to changing network conditions
- Aggressive CDN edge caching keeps playback latency low and origin load minimal at massive scale
- Separating catalog/recommendation metadata from video delivery lets each scale independently
- Pre-transcoding once per title (not per view) trades a fixed upfront encoding cost for near-zero per-view compute
AI Mentor Explanation
A streaming platform is like a broadcaster preparing multiple pre-recorded highlight feeds at different quality levels — HD for a stadium screen, lower quality for a spotty regional relay — instead of encoding fresh footage live for every single viewer, mirroring multi-bitrate transcoding done once per match. Each viewer’s device constantly checks its own connection and switches to whichever quality feed it can sustain without stuttering, exactly like adaptive bitrate streaming. Regional relay towers cache the feed locally so most fans never pull directly from the central broadcast truck, mirroring CDN edge caching. And the match statistics and commentary archive are stored completely separately from the video feed itself, just like metadata being decoupled from video delivery.
Step-by-Step Explanation
Step 1
Ingest and transcode
A newly uploaded title is split into short chunks and encoded at multiple bitrates/resolutions, producing an HLS/DASH manifest listing every rendition.
Step 2
Distribute to CDN edges
Encoded chunks are pushed and aggressively cached at CDN edge nodes (including ISP-embedded appliances) close to viewers ahead of demand.
Step 3
Adaptive playback
The client player measures throughput and buffer health continuously, requesting each next chunk at the bitrate that best fits current network conditions.
Step 4
Serve metadata separately
Catalog browsing, recommendations, and viewing history are served from an independently scaled metadata service, decoupled from the video delivery path.
What Interviewer Expects
- Explains chunk-based multi-bitrate transcoding done once per title, not per view
- Describes adaptive bitrate streaming and how the client selects renditions dynamically
- Mentions CDN edge caching (and that video delivery dominates the scaling problem, not metadata)
- Separates catalog/recommendation metadata from the video delivery path explicitly
Common Mistakes
- Proposing on-the-fly transcoding per view instead of pre-transcoding once per title
- Ignoring adaptive bitrate streaming and assuming a single fixed video quality for all viewers
- Serving video directly from an origin data center instead of CDN edge caching
- Coupling the recommendation/metadata service tightly with the video delivery pipeline
Best Answer (HR Friendly)
“A streaming platform like Netflix works by processing every show or movie once, in advance, into several different quality versions, rather than converting it fresh every time someone watches. Your device then automatically picks whichever quality version fits your current internet speed, adjusting smoothly if your connection changes, and the actual video is served from a server near you rather than one far-away data center. All the browsing and recommendation stuff you see is handled by a completely separate, much lighter system from the video itself.”
Code Example
title: "example-movie"
segmentDurationSeconds: 6
renditions:
- name: "1080p"
bitrateKbps: 5000
resolution: "1920x1080"
playlist: "1080p/index.m3u8"
- name: "720p"
bitrateKbps: 2800
resolution: "1280x720"
playlist: "720p/index.m3u8"
- name: "480p"
bitrateKbps: 1200
resolution: "854x480"
playlist: "480p/index.m3u8"
- name: "240p"
bitrateKbps: 400
resolution: "426x240"
playlist: "240p/index.m3u8"
cdn:
edgeCacheTtlSeconds: 86400
originShield: trueFollow-up Questions
- How would you decide which bitrate to request next in an adaptive bitrate player?
- How does pre-positioning content at ISP-embedded CDN caches reduce backbone traffic?
- How would you design the recommendation service so it never blocks video playback?
- How would you handle a viral live event that spikes concurrent viewers far beyond normal catalog traffic?
MCQ Practice
1. Why is video transcoded once per title into multiple bitrates instead of per view?
Transcoding is CPU-intensive, so it is done once at ingest time and reused for every subsequent playback, rather than repeating the cost per viewer.
2. What does an adaptive bitrate (ABR) player primarily optimize for?
ABR continuously measures network conditions and buffer state to pick the rendition that plays smoothly without excessive buffering.
3. Why is the metadata/recommendation service kept separate from video delivery?
Catalog browsing and recommendations are small, query-heavy workloads, while video delivery is massive, bandwidth-heavy streaming — separating them lets each scale independently.
Flash Cards
Why transcode once per title? — Transcoding is expensive; doing it once at ingest amortizes cost across all future views instead of repeating it per view.
What does adaptive bitrate streaming do? — The client dynamically picks the best-fitting video rendition based on current network throughput and buffer health.
Why use CDN edge caching for video? — It serves chunks from locations close to viewers, minimizing latency and origin load at massive scale.
Why separate metadata from video delivery? — They have very different scaling and latency profiles, so coupling them would hurt both.