Netflix

Video streaming platform

Design an on-demand video service: prepare each title in many qualities, deliver the bytes from servers close to viewers, adapt quality to each viewer's network, and remember where everyone stopped.

Overview

A streaming service looks like one product, but the design splits it in two. The control plane is everything except the video bytes: sign-in, the home page, search, deciding which files a device should play and where to fetch them. The data plane is the video itself: very large files, read many times, sent at a steady rate for hours.

Netflix has documented this split in its own write-ups. Its business logic, databases, recommendations and transcoding run in AWS, and video is delivered by Open Connect, its own CDN of appliances placed at internet exchanges and inside ISP networks. The control plane tells each device which appliance to fetch from; the appliance only serves files.

The interview tests whether you see why the split exists (the two halves have completely different load shapes) and whether you can go deep on the parts that make playback smooth: encoding each title into a ladder of qualities, putting the files near viewers before they are needed, and letting the player pick a quality every few seconds.

Questions to ask first

Live or on demand? — On demand only; live events are a different design
How many viewers at peak? — 50 million concurrent streams, 5 Mbps on average
How big is the catalog? — About 20,000 hours of content, adding new titles weekly
Which devices? — TVs, phones, browsers; each has its own codecs and screen limits
What does 'good' mean? — Fast start, no stalls, the best quality the network allows
Must progress sync across devices? — Yes, within a minute

What you will be able to do

Explain why video delivery is separated from the rest of the service, and what each half needs.
Walk a title from master file to a per-title ladder of encodes, and say why encoding by shot helps.
Describe how a player picks a bitrate every few seconds, and simulate it.
Explain proactive fill and client steering, and how a big release is handled.
Store viewing progress so resume works across devices, and keep the home page up when recommendations fail.

Key concepts

Control plane vs data plane
Open Connect Appliances
Proactive nightly fill
Client steering
Per-title encoding
Shot-based encoding
Adaptive bitrate
Viewing history
Precomputed home rows
Chaos engineering

Functional requirements

Browse a personalized home page and open a title
Press play and start video within a couple of seconds
Change quality automatically as the network changes
Resume from where the profile stopped, on any device
Add new titles to the catalog every week

Non-functional requirements

Playback starts in under 2 seconds at p90 (a target we chose)
Stalls (rebuffering) in well under 1% of viewing time (a target we chose)
Browsing survives the loss of a whole cloud region
Video keeps playing if the control plane is briefly unavailable, because appliances serve files on their own
Delivery cost per hour watched keeps falling as viewing grows

Interview questions

Why separate the control plane from video delivery?
How does adaptive bitrate streaming work?
How would you handle the release of a very popular new season?
What happens when a user switches from the phone to the TV?
How is a new title encoded, and why per shot?
How does the CDN know what to store where?
How do you personalize the home page without making it fragile?
How would the design change for live events?