Design Netflix
The interviewer asks
“Design Netflix: a subscription video service with a curated catalogue of films and series, streamed in high quality to hundreds of millions of members on TVs, phones and browsers. Focus on how video gets to the screen quickly and reliably, and on the browse experience.”
What a strong answer looks like
Netflix differs from YouTube in one key way: the catalogue is small, known in advance and professionally produced, while viewing is enormous and concentrated in the evening. A strong answer exploits that. Content is encoded once with per-title or per-shot optimisation into many bitrate/codec/language combinations and protected with DRM. Video is pre-positioned during off-peak hours onto cache appliances inside ISPs (Open Connect), so at prime time almost every byte comes from a box one network hop from the viewer. The control plane runs in the cloud across multiple regions: a playback service that checks entitlement, issues DRM licences and steers each client to the best caches, plus the personalised browse page served from precomputed recommendations and a large in-memory cache. Deep dives: proactive caching and steering, encoding optimisation, the playback/licence path, and resilience of the cloud control plane (multi-region, fallbacks, chaos testing).
Concepts to mention
1 Requirements
Functional
- Members browse a personalised home page of rows and artwork, search, and see title details
- Play a title on any device with adaptive quality, multiple audio languages and subtitles
- Resume where you left off across devices; track viewing history
- Enforce subscription plan rules: resolution (SD/HD/4K) and number of simultaneous streams
- Protect content with DRM (Widevine, PlayReady, FairPlay)
- Downloads for offline viewing on mobile
Non-functional
- ~300M members; peak ~40-50M concurrent streams in the evening
- Playback start < 2 s p90 on broadband; rebuffering in < 0.5% of sessions
- Streaming 99.99% available; browse may degrade (e.g. generic rows) but must not fail
- Peak egress in the hundreds of Tbps, served mostly from inside ISP networks
- Home page API < 300 ms p99 globally
- Content licensing: titles available only in licensed countries; data and logs handled per local law
Out of scope (say it out loud)
- Billing and payments
- Recommendation model training details
- Studio production tools and content ingestion from partners (mention briefly)
- Live events (separate live-streaming design)
2 Estimates
3 API
| Endpoint | What it does |
|---|---|
GET/v1/home?profileId=…&device=tv | Personalised home page: rows, titles and chosen artwork, assembled for the device |
GET/v1/titles/{id} | Title details, episodes, maturity rating, available languages |
POST/v1/playback/manifest | Given title, device capabilities and network, return the stream list (codecs, bitrates, audio, subtitles) and ranked cache URLs |
POST/v1/playback/license | DRM licence request: check entitlement and stream limit, return content keys bound to the device |
POST/v1/playback/heartbeat | Every ~60 s during playback: position, bitrate, rebuffers; enforces concurrent stream limits |
GEThttps://oca-xyz.isp.nflxvideo.net/range/… | Byte-range fetch of video/audio from an Open Connect appliance |
GET/v1/search?q=… | Search titles, people and genres in the member's country catalogue |
4 Data model
titlesCassandra + in-memory replicated cachetitle_idtypemetadata per localematurityavailability windows per countryencode asset idsSmall dataset read constantly; services keep it in memory and refresh from a publish pipeline.
viewing_history / bookmarksCassandra (multi-region)profile_id (partition)title_idposition_secondsupdated_atWrite-heavy (heartbeats), last-writer-wins is fine; replicated across regions so resume works after failover.
active_streamsEVCache / Redis with TTLaccount_id → {device_idsession_idlast_heartbeat}Enforces plan stream limits; entries expire ~2-3 minutes after heartbeats stop.
precomputed home pagesEVCache (Memcached-based)profile_id + device → list of rows (row_type, title_ids, artwork ids)Computed offline/nearline by recommendation jobs; served directly at request time with a fallback to popular rows.
encoded assetsS3 (origin) + Open Connect appliancesasset_idcodecbitrateresolutionlanguagefileS3 is the master copy; appliances hold the popular subset per region.
cache placementControl-plane DBappliance_idlocationISPhealthstored asset idsBGP prefixes servedUsed by steering to pick appliances near the client that actually hold the file.
playback eventsKafka → data lake (Iceberg on S3)session_iddevicebitrate switchesrebufferserrorsstartup timeDrives QoE dashboards, A/B tests and encoding decisions.
5 Architecture
Hover a box to highlight its connections.
6 Request flows
Press play
- 1The player calls /playback/manifest with title id, device capabilities (codecs, HDR, max resolution, DRM type) and plan.
- 2The playback service checks entitlement (plan, country availability, maturity) and builds the list of streams that fit the device: e.g. AV1 or HEVC up to 1080p, Hindi and English audio, subtitles.
- 3Steering picks 2-3 healthy cache appliances that hold those files and are closest to the client in network terms (the appliance announces the ISP's BGP prefixes it serves), and returns their URLs ranked.
- 4The player requests a DRM licence; the licence service checks the concurrent-stream limit (active_streams), then returns content keys bound to this device.
- 5The player fetches the first few seconds at a modest bitrate from the top-ranked appliance with byte-range requests, starts playback, then climbs the bitrate ladder as its buffer grows.
- 6If an appliance is slow or fails, the player switches to the next URL in the list without stopping.
- 7Every ~60 s a heartbeat updates the bookmark in Cassandra and refreshes the stream-limit entry.
Nightly cache fill
- 1The fill planner predicts what each region and ISP will watch tomorrow: new releases, regional popularity (a new Hindi series for Indian ISPs), and current trends.
- 2It computes, for each appliance cluster, which files to add and which to evict.
- 3During the local off-peak window (early morning), appliances download new files from S3 or from peer appliances with spare capacity.
- 4By evening, the popular catalogue for that ISP sits on its appliances, so prime-time traffic never crosses the ISP's transit links.
Open the app
- 1The app calls /home for the active profile and device type.
- 2The home service reads the precomputed page (rows like 'Continue Watching', 'Because you watched X', 'Top 10 in India') from EVCache.
- 3It applies real-time adjustments: titles just finished are removed, Continue Watching is refreshed from bookmarks, unavailable titles are filtered.
- 4If the personalised page is missing or the reco system is down, it falls back to cached popular rows for the country, so the page always renders.
7 Deep dives
Proactive caching inside ISPs and client steering
With a known catalogue and predictable demand, Netflix does not wait for cache misses. Its Open Connect appliances (storage-heavy servers given free to ISPs or placed at internet exchanges) are filled every night during off-peak hours with the files each location is predicted to need. Popularity is very skewed, so a box with a few hundred TB holds the content behind most of that ISP's viewing. Fill uses a tiered approach: appliances can fill from peers, reducing load on the cloud origin. At play time, the steering service in the cloud chooses appliances for each client: the appliance must hold the needed files, be healthy, have spare capacity and be 'close' in network terms (appliances report the BGP routes the ISP gives them, so steering knows which client prefixes each appliance serves best). The client gets several ranked URLs and fails over between them on its own. The result: at prime time, around 95%+ of bytes are served from inside or next to the viewer's ISP, latency is low, and the ISP saves transit cost, which is why ISPs agree to host the boxes.
Encoding: per-title and per-shot optimisation
A fixed bitrate ladder (say 1080p always at 5.8 Mbps) wastes bits on a simple cartoon and starves a grainy action film. Netflix moved to per-title encoding, choosing the ladder for each title by measuring quality (VMAF, a perceptual metric) at many resolution/bitrate points and picking the convex hull. It later went further to per-shot (dynamic optimizer) encoding, where each shot gets its own encoding parameters. The result is the same visual quality at noticeably lower bitrate, which matters for mobile users in India on data plans and for total egress. The pipeline splits the studio mezzanine file into chunks, encodes chunks in parallel on a large batch compute fleet, validates every output (automated checks for artefacts, sync, missing frames), and packages encrypted segments. Because each title is encoded once and watched millions of times, it pays to spend heavy compute: AV1 and HEVC encodes for capable devices, H.264 for compatibility, and special low-bitrate mobile encodes.
The playback control path: entitlement, DRM and stream limits
Everything before the first video byte runs in the cloud and must be fast and highly available, because a failure means no playback at all. The manifest call evaluates entitlement (plan, region availability windows, maturity rules) and device capability, so the response lists only streams the device can decode and the member may watch (4K only on the premium plan). The licence call issues DRM keys: Widevine for Android and Chrome, FairPlay for Apple, PlayReady for many TVs and Windows. Licences are bound to the device and expire, and offline downloads carry licences with longer expiry and a download count limit. Concurrent stream limits are enforced with heartbeats and a TTL entry per active session: a fifth device on a four-screen plan is refused, and a crashed device's slot frees itself after the TTL. These services are stateless, replicated in several AWS regions, and backed by replicated caches so a regional failure does not stop playback.
Resilience of the cloud control plane
The control plane is hundreds of microservices, so something is always failing. Patterns that keep the product up: every service call has a timeout, a circuit breaker and a fallback (if the personalised row service is down, show popular rows; if the bookmark read fails, start from the beginning rather than refusing to play). Critical paths (playback start, licence) are kept as short and dependency-light as possible, while non-critical calls are made optional. Requests carry priority so that under overload the gateway sheds low-priority traffic (prefetching artwork, logging) before playback. The whole control plane runs active-active in several regions with Cassandra and EVCache replicated across them; if a region degrades, traffic is shifted by DNS and gateway rules within minutes. Netflix popularised chaos engineering (Chaos Monkey and region evacuation drills) precisely to prove that these fallbacks work before a real failure tests them.
8 Trade-offs
Proactive fill vs pull-through caching
Pull-through caching (fetch on first miss) is simpler and fits a huge long-tail catalogue like YouTube. Netflix's small, predictable catalogue makes proactive fill better: no prime-time miss storms and fill traffic moved to off-peak hours when bandwidth is cheap. The cost is a prediction system and a little wasted storage.
Own CDN appliances vs commercial CDN
At hundreds of Tbps, owning the appliances is cheaper and gives full control over steering and protocols. It requires partnerships with thousands of ISPs and a hardware operations team, which only makes sense at very large scale.
Precomputed home pages vs computing on request
Precomputing rows offline makes the home API fast and resilient but can be stale. A hybrid applies cheap real-time adjustments (continue watching, remove just-watched titles) on top of the precomputed page.
Heavy encoding compute vs bandwidth
Per-shot and AV1 encoding cost much more compute per title, but each title is streamed millions of times, so bandwidth savings dominate. For a long-tail UGC platform the maths is different.
9 Bottlenecks
New season launch
A global release at a fixed time sends millions of plays in the first hour. Pre-fill the episodes everywhere days before, pre-scale playback and licence services, and stagger non-essential calls such as artwork prefetch.
ISP link saturation
If an ISP's appliances run out of capacity, steering spills clients to the nearest exchange-point cluster. Health and load are reported continuously so steering reacts in seconds.
Hot partitions in viewing history
Heartbeats every minute from 45M streams are ~750k writes/s. Cassandra partitioned by profile id spreads them; keep writes small and use LWW columns instead of read-modify-write.
10 Failure handling
A cache appliance dies mid-stream
The player already holds alternative URLs; it retries the next segment range from another appliance. The viewer may see a short quality dip, not a stop. Steering stops sending clients to the failed box within seconds.
An AWS region degrades
Traffic for the control plane is evacuated to other regions (all regions run active-active with replicated data). Streams already playing continue from appliances; new plays route to healthy regions.
Recommendation system down
The home service falls back to cached country-level popular rows. The page looks less personal but works.
Licence service slow
Licences are short calls with strict timeouts and retries across regions. Recently issued licences remain valid for their lifetime, so ongoing playback is not affected.
11 What impresses
- Explains why Netflix fills caches proactively while YouTube relies on pull-through, from catalogue shape
- Separates the cloud control plane from the data plane in ISPs
- Mentions per-title/per-shot encoding and its bandwidth benefit for mobile users
- Designs graceful degradation: every non-critical dependency has a fallback
- Handles stream limits with TTL heartbeats so crashed devices free their slot
- Brings up launch-day pre-positioning and pre-scaling
12 Mistakes
- Serving video from cloud application servers or a single origin
- Treating Netflix exactly like YouTube and ignoring the catalogue difference
- Making playback depend on the recommendation system being healthy
- Forgetting DRM and plan entitlement in the play path
- One region only, with no failover story
- No numbers for egress, so the CDN choice is never justified
13 Follow-ups
Lessons this design uses
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.