System design interview · Hard · about 45 minutes

Design Netflix

Design a subscription video streaming service like Netflix. A curated catalog is uploaded by the company (not users), and millions of subscribers stream it worldwide on every kind of device.

videoCDNrecommendations

Practise it in the interview simulatorDraw your design on a canvas, stress test it with real traffic, and get a scored report. Or watch this answer build itself, step by step.

1. Clarify the requirements

Before drawing anything, ask questions. These are the answers an interviewer would typically give:

How many users?: 200 million subscribers; at peak 20 million stream at once.
Who uploads?: Only the studio team, a few thousand titles a year. Upload volume is tiny compared to playback.
Bitrate?: HD streams are about 5 Mbps.
Which features?: Browse catalog, personalized home page, playback with resume ('continue watching'). Downloads and live are out of scope.
Geography?: Worldwide, with content licensing that differs per country.

2. Estimate the scale

Assumptions: 20M concurrent streams at peak, 5 Mbps each.

Peak egress bandwidth: about 100 Tbps20M × 5 Mbps = 100,000,000 Mbps = 100 Tbps. Only a CDN (or your own) can serve this.

3. The high-level design

The reference design. Dashed arrows are asynchronous.

Viewers reach an API gatewayA gateway routes requests to many stateless microservices and protects them with rate limits and fallbacks.
Catalog in a cache and a databaseTitles, artwork and personalised rows are read on every screen: cached in memory, backed by a replicated database.
Encode every title ahead of timeWhen a title arrives, an encoding pipeline produces many bitrates and codecs per scene, in parallel. This never happens on a viewer's request.
Stream from the CDNVideo bytes come from CDN boxes inside internet providers, close to viewers; players switch bitrate as the network changes.
Viewing events, asynchronouslyPlayers send heartbeats (what's watched, where they paused). They go to a log and are processed in the background, so playback never waits.
Watch it in productionMetrics and alerts close the loop: stream starts per second (the key metric), rebuffering and per-service error rates.

4. The components and what each one does

API gateway API gateway: Routes to microservices; rate limits; graceful fallbacks when a service is slow.
Playback & catalog API Service: Stateless microservices: what to show, which files to play, which CDN box to use. Circuit breakers isolate failures.
Catalog cache Cache · EVCache: Titles, artwork and personalised rows, cached across zones.
Catalog DB NoSQL / KV store · Cassandra: Titles and profiles; replicated across regions, with failover to another region if one goes down.
Encoding pipeline Workers: Encode each scene in many bitrates and codecs, in parallel. Runs when a title arrives, not on user requests.
Encoded video Object storage · S3: Every bitrate of every title: the CDN's origin.
Open Connect CDN CDN: CDN boxes inside ISPs hold the popular catalogue: most bytes never cross the internet.
Viewing events Event stream · Kafka: Playback heartbeats.
Event processors Workers: Update viewing history and feed recommendations.
Viewing history NoSQL / KV store · Cassandra: Per-profile history; partitioned by profile; replicated.
Metrics & alerts Metrics & alerts: Dashboards and alerts on p99 latency, error rate, queue depth and cache hit ratio, so a bottleneck shows up before it becomes an outage.

5. Deep dive: global delivery & personalization

How do you deliver 100 Tbps worldwide? How is content pre-positioned, and how are personalized home pages built?

Pre-position (push) popular titles to CDN/edge caches inside ISPs during off-peak hours.
Encode each title once into many bitrates/resolutions; stream with adaptive bitrate.
Recommendations are computed offline (batch) and served from a cache.

6. What interviewers listen for

Pre-position popular content at the edgePushing tomorrow's popular titles to edges overnight avoids cache misses at peak.
Adaptive bitrate streamingPlayers adapt quality to bandwidth so playback doesn't stall.
Recommendations computed offline, served from cachePersonalized rows are computed in batch and cached; the home page just reads them.
Per-country licensing / geo restrictionsCatalog availability differs by country.
DRM / encryptionStudios require DRM.
Database replication and failoverA single database is a single point of failure. Replicas give redundancy and read capacity; failover promotes a replica when the primary dies.
Partition (shard) data as it growsOne machine eventually can't hold the data or the write load. Say how you'd split it and by which key.

7. Follow-up questions

A hugely anticipated season drops at midnight worldwide. How do you avoid the edges melting down?
An entire cloud region hosting your control plane (login, catalog API) goes down. What do viewers experience?

Answer them in the simulator

The key points for each follow-up, your scored report and the stress test are part of Pro: ₹299 a month or ₹1,999 a year.

See Pro

The design in a nutshell

Studio uploads masters → object storage → encoding pipeline (many codecs/bitrates) → renditions in object storage.
Popular titles are pushed to edge caches inside ISPs off-peak; clients stream via adaptive bitrate from the nearest edge.
Control plane (auth, catalog, playback API, watch progress) runs multi-region behind load balancers with replicated databases + caches.
Recommendations computed offline and cached per profile; DRM licenses issued by a license service.