How to Design a Video Streaming Service Like Netflix
Design a streaming service as two systems. A slow write path prepares each video, and a fast read path delivers it. Almost all the traffic is reads, so most of the design effort belongs in delivery.
One upload can become millions of views. That ratio decides everything. Say it in your first minute and the interviewer knows you understand the shape of the problem.
The hard part is not the database. It is moving tens of terabits per second of video close to users without buffering.
Requirements to agree on first
State the features you will build:
- Upload and publish a video title.
- Browse and search the catalog.
- Play a title on a phone, a browser, or a TV.
- Resume from the last watched position.
- Manage accounts and subscriptions.
State the qualities the system must have:
- Availability. Playback must survive a lost server or a lost region.
- Fast start. Aim for under two seconds to the first frame.
- Smooth playback. Quality drops before the video stops.
- Durability. A master video file must never be lost.
Then say what you are cutting. Recommendations, billing, and content rights are normal cuts for a 45 minute round.
Scale estimate
Numbers guide the design, so do the arithmetic out loud.
| Quantity | Assumption | Working number |
|---|---|---|
| Daily viewers | 100 million | 100 million sessions a day |
| Watch time each | 2 hours | 200 million hours a day |
| Streams at once | Average across the day | about 8 million |
| Average bitrate | 5 Mbps | about 40 Tbps average |
| Peak traffic | 2x average | about 80 Tbps |
| One two hour title | 10 renditions | about 30 GB encoded |
No origin server farm serves 80 Tbps. That single number is why a content delivery network, a CDN, is the center of the answer.
The write path: upload and transcoding
A publisher uploads one very large master file. The system turns it into many small, playable pieces.
- Store the master file in object storage such as Amazon S3.
- Split it into chunks of a few seconds each.
- Transcode the chunks in parallel on a worker fleet. Each worker writes one rendition, meaning one resolution and bitrate pair.
- Package the output into segments of 2 to 10 seconds, with a manifest file that lists them. HLS and DASH are the two common formats.
- Write the segments back to object storage.
- Publish the title by copying segments to the CDN and marking it live in the metadata store.
Put a queue between the steps. A message queue lets one failed chunk retry on its own, instead of redoing the whole title.
Mention per-title encoding if you want depth. Netflix picks the bitrate ladder per title rather than using one fixed ladder. A cartoon and an action film do not need the same bitrate for the same quality.
The read path: CDN and playback
The CDN stores copies of segments close to viewers. Netflix runs its own, called Open Connect, and places appliances inside internet provider networks.
Netflix fills those appliances ahead of demand. Popular titles are pushed out during quiet hours, before anyone asks for them. That is a planned fill, not a cache miss.
Playback then works in three steps:
- The player asks the control plane for the manifest and a signed URL.
- The control plane points it at the nearest healthy appliance.
- The player pulls segments straight from that appliance.
Adaptive bitrate keeps playback smooth. The player measures download speed and how much buffer is left. It then picks the quality of the next segment. Quality can change at every segment boundary, so a weak network lowers resolution instead of stopping.
Where each kind of data lives
| Data | Store | Why |
|---|---|---|
| Video segments | Object storage plus CDN | Large, immutable, read constantly |
| Title metadata | Relational or document store | Small, structured, heavily cached |
| Watch position | Wide-column store such as Cassandra | Huge write rate, simple key lookups |
| Search index | Search engine such as Elasticsearch | Text matching and filters |
| Events and logs | Stream such as Kafka | Feeds analytics and recommendations |
Put a cache in front of metadata. The same title page is requested millions of times an hour, and the data changes rarely.
Availability and failure
Keep the services stateless behind load balancers, so any instance can serve any request. Run in several regions and move traffic away from a failing one.
Degrade instead of failing. If recommendations are down, show a static row. If search is down, still allow playback.
Netflix tests this by causing failures on purpose in production. That practice is called chaos engineering.
How to Prepare
- Learn the building parts first. Grokking System Design Fundamentals covers CDNs, caching, and replication before you attempt a full design.
- Practice the full question. Grokking the System Design Interview walks through this design and others in the same format.
- Compare with the real architecture. Read the system design of Netflix and the design architecture of Netflix.
- Know the company set. Review the top system design questions asked at Netflix.
- Say the numbers out loud. Practice the traffic estimate until you can do it in two minutes without notes.
GET YOUR FREE
Coding Questions Catalog
$123
$197
$72
