Design Netflix

Design Netflix — the 45-minute interview walkthrough

This lesson is the interview version of designing a video streaming service: how to pace the discussion and which deep dives to prepare. The full reference design is the case study Design Netflix in this chapter, and the more general Video Streaming Platform case covers user uploads (YouTube style).

What makes this problem distinctive is that the bytes dominate everything. Video is enormous, so the design is really about getting the right encoded file segments physically close to viewers before they press play. The "application" part (catalogue, accounts, recommendations) is conventional microservice work by comparison.

Minutes 0–5: clarify requirements

• Core features: browse the catalogue, search, watch a title with smooth playback on many device types, resume where you left off, personalized home rows.
• Out of scope unless asked: user uploads (Netflix content comes from studios), live streaming, payments.
• Scale assumptions: ~200M+ subscribers, tens of millions of concurrent streams at evening peak, a catalogue of tens of thousands of titles, each encoded into many versions.
• Quality goals: playback starts in about 1–2 seconds, rebuffering is very rare, and quality adapts to the network.
• Availability matters more than strict consistency. A slightly stale "continue watching" row is fine. Playback failing is not.

A quick bandwidth estimate shows why the CDN is the design: 10M concurrent streams × ~5 Mbps ≈ 50 Tbps. No central data centre serves that. It has to come from thousands of edge locations.

Minutes 5–15: high-level design

            ┌──────────── Control plane (cloud region) ────────────┐
 device ──▶ │ API gateway → catalogue · search · profiles · playback│
            │               · recommendations · viewing history     │
            └───────────────────────┬──────────────────────────────┘
                                    │ playback service returns a manifest + CDN URLs
                                    ▼
 device ◀── video segments ── CDN edge servers (inside ISPs / exchange points)
                                    ▲
                                    │ nightly pre-positioning of popular titles
 studio master ─▶ ingest ─▶ encoding pipeline ─▶ origin object storage

Separate the two planes out loud:

• The control plane handles small requests: what to show, whether the user is allowed to play something, which servers to use.
• The data plane (the CDN) handles the huge byte stream.

Minutes 15–35: deep dives

1. The encoding pipeline

A studio master file is transcoded into a bitrate ladder: many resolution and bitrate combinations (roughly 240p to 4K), several codecs (H.264 for compatibility, and HEVC, VP9 and AV1 for efficiency), plus audio tracks and subtitles. Each version is cut into small segments of a few seconds.

• The pipeline splits the source into chunks and encodes them in parallel across many workers, then reassembles them. That's a classic embarrassingly parallel batch job coordinated by a workflow engine, with retries per chunk.
• Per-title (and per-scene) encoding tunes the ladder to the content's complexity. A cartoon needs far fewer bits than a grainy action film at the same visual quality, which saves significant bandwidth.
• Outputs go to durable object storage (the origin), along with manifests that list the available renditions and segment locations.

2. Adaptive bitrate streaming

The player downloads a manifest (HLS or DASH), then fetches segments over plain HTTP. It continuously measures throughput and buffer level, and picks the rendition for the next segment: higher quality when the buffer is healthy, lower when it's draining. Since every segment boundary is a possible switch point, quality adapts without stalling. Plain HTTP segments also mean any HTTP cache or CDN can serve them.

3. The CDN and pre-positioning

• Netflix runs its own CDN (Open Connect): cache servers placed inside ISP networks and at internet exchange points, so most traffic never crosses the wider internet.
• Viewing is highly predictable (new releases, regional favourites), so popular content is pre-positioned during off-peak hours based on predicted demand, rather than filled on the first cache miss.
• The playback service (in the control plane) chooses which edge servers a client should use, based on the client's network, server health and load, and what content each server holds. It returns a ranked list, so the client can fail over.

4. The control-plane services

• Catalogue and metadata: read-heavy and cached aggressively; changes rarely.
• Viewing history / "continue watching": high write volume (periodic progress heartbeats), so a wide-column store partitioned by profile fits well. Eventual consistency is fine.
• Recommendations: computed largely offline (batch models over viewing history) and served from precomputed per-profile rows, with a light online re-ranking step.
• Resilience: each call has timeouts, circuit breakers and fallbacks. If personalization is down, show popular titles. The home page should degrade, never fail. Netflix popularized chaos engineering (deliberately killing instances in production) to prove these fallbacks work.
• DRM and licensing: a license service issues decryption keys per playback session, and enforces regional rights and device limits.

Minutes 35–45: trade-offs and wrap-up

• Storage vs bandwidth: more encoded renditions cost storage and encoding compute, but save far more bandwidth and improve quality. With this many viewers, bandwidth dominates.
• Pre-positioning vs pull-through caching: predictable demand makes proactive filling efficient. Long-tail titles are fetched from upstream tiers on demand.
• Availability over consistency in the control plane, with graceful degradation.
• With more time: multi-region active-active control plane, live events (a different latency and fan-out problem), downloads for offline viewing, and A/B testing infrastructure.

Common mistakes in interviews

• Serving video from application servers, or from a single origin behind a generic CDN, without discussing bandwidth.
• Forgetting adaptive bitrate. A single file per title can't handle varied networks and devices.
• Spending the whole interview on the recommendation algorithm, which is a separate ML problem.
• No failure story for dependencies: what the home page shows when one service is down.

Follow-up questions this topic invites — and their answers

Q: Why cut videos into small segments instead of streaming one file? A: Segments let the player switch quality at every boundary, make every request a cacheable HTTP GET, allow parallel and resumable downloads, and let playback start after only the first few seconds arrive.

Q: How does the player decide which quality to fetch? A: It combines measured throughput and current buffer level. When the buffer is full and throughput is high, it steps up. When the buffer drains, it steps down quickly to avoid a stall. Modern algorithms weigh the buffer heavily, because throughput estimates are noisy.

Q: What happens when an edge server fails mid-stream? A: The client already has a ranked list of alternative servers from the playback service. It requests the next segment from another server. Because it has seconds of buffer, the switch is usually invisible to the viewer.

Q: How is "continue watching" kept up to date? A: The player sends periodic progress heartbeats. They're written, often via a queue, to a store partitioned by profile ID. Reads just need the latest position per title, and seconds of staleness are acceptable.

Q: How would you support a live event with millions of viewers? A: Use a live encoder producing short segments continuously, and manifests that are updated as new segments appear. Push segments to CDN tiers immediately, and use request collapsing at the edges so a million simultaneous requests for the newest segment become one upstream fetch. The latency target and the synchronized load make it a different problem from on-demand video.