SDE Path

Streaming & CDN at scale

Design Netflix

Hard

Stream 4K video to tens of millions of viewers at once — filling the internet's pipes without a buffering spinner.

Netflix is a subscription video-on-demand service: a curated catalog of movies and shows that members browse, get recommendations for, and stream on any device. Unlike a user-upload platform, content arrives in bulk from studios and is processed offline, long before anyone presses play.

Two facts shape the entire design:

  • Every title is pre-encoded offline into an adaptive-bitrate (ABR) ladder — dozens of resolution/bitrate/codec variants, chopped into small segments — so the player can switch quality on the fly.
  • Playback is overwhelmingly read-heavy and bandwidth-dominated. Tens of millions of concurrent streams mean hundreds of terabits per second of egress. No origin datacenter can serve that; the bytes must come from caches inside ISPs (Open Connect).

So the hard parts aren't uploads or transactions — they're massive CDN/edge delivery and a recommendation pipeline that decides what every member sees. This is the canonical "read-heavy delivery at planet scale" interview.

Start by scoping. The interviewer wants to see you separate the control plane (browse, recommend, authorize playback — small JSON traffic) from the data plane (the actual video bytes — hundreds of Tbps served from the edge). That split, plus "curated catalog pre-encoded offline," drives every later decision. This is not a user-upload site.

Functional

  • Browse & personalized home — the home page is rows of ranked titles per profile, plus catalog search.e.g. "Trending", "Top 10", "Because you watched …", genre rows. Multiple profiles (with maturity ratings) live under one account.
  • View a title's detail page — synopsis, cast, episodes, and artwork metadata.
  • Adaptive playback of any title across devices — authorize a play, then stream ABR segments from the edge.
  • Resume / continue watching — track viewing progress so playback resumes where the member left off.The same viewing history also feeds recommendations.
  • Offline content ingestion — studio masters are validated and pre-encoded into an ABR ladder, then distributed to the edge.

Non-functional

  • Massive read/stream scale — ~250M subscribers; tens of millions of concurrent streams at prime time.
  • Huge egress bandwidth — peak global egress on the order of hundreds of Tbps, served from edge caches.
  • Fast start + smooth playback — start < 2 s; rebuffer ratio < 0.5% of play time.
  • Playback availability 99.99% — streaming must not go down at prime time.
  • Adaptive quality — degrade gracefully from ~235 kbps up to ~15 Mbps 4K as the network changes.
  • Global proximity — bytes served from an edge within tens of ms RTT of the viewer; catalog masters at 11 nines durability.

Out of scope

  • Live streaming / real-time sports
  • User uploads & UGC moderation
  • Billing/payment internals (assume an active subscription)
  • DRM cryptography & content-protection legalities

Check yourself· 3 questions

Question 1

What is the dominant technical challenge in Netflix versus a user-upload video site?

Question 2

Why pre-encode every title offline into a fixed ABR ladder instead of transcoding on demand at play time?

Question 3

Why separate the control plane (browse/recommend/authorize) from the data plane (video byte delivery)?