FSD Frontend System Design

Part VI — The Blueprint · Lesson 11.5

HLD – Video Streaming (Netflix)

In one lineAdaptive bitrate keeps the buffer full — every other decision serves that one goal.

Where you've seen itVideo quality softening for a few seconds in a tunnel, then recovering, without ever showing a spinner.

  • Time20 min
  • DiagramABR ladder + buffer state machine
  • Chapter11 · High Level Design

Diagram

diagram
1–2 · SCOPE AND SCALE

  in scope   browse rows · title page · player · continue watching
  out        recommendations ML · billing · downloads · profiles admin
  scale      250M subscribers · 4K streams up to 25 Mbps
             TV / laptop / phone · network varies mid-playback
diagram
3 · ARCHITECTURE

  ┌────────┐  manifest (HLS/DASH)  ┌─────────────┐
  │ Player │◄─────────────────────►│  CDN edge   │
  └───┬────┘  2–10s segments        └─────────────┘
      │                                    ▲
      │ metadata, rows, continue-watching  │ segments pre-positioned
      ▼                                    │ at edges worldwide
  ┌─────────┐        ┌──────────────────────────┐
  │   BFF   │───────►│ catalog · playback · CDN │
  └─────────┘        │ auth (DRM licence)       │
                     └──────────────────────────┘
diagram
6a · DEEP DIVE — THE ABR LADDER

  the same title, encoded many times

  2160p  25 Mbps  ████████████████████████
  1080p   5 Mbps  ██████
   720p   3 Mbps  ███
   480p   1 Mbps  █
   240p 300 kbps  ▏

  each rendition is cut into 2–10s segments; the manifest lists them

  every segment boundary, the player asks:
    measured throughput + current buffer level
        │
        ├─ buffer healthy & bandwidth up   → step UP one rung
        ├─ buffer draining                 → step DOWN immediately
        └─ never jump more than one rung up (avoids oscillation)
diagram
6b · DEEP DIVE — BUFFER STATE MACHINE

  [empty] ──fill 2s──► [playable] ──fill 30s──► [healthy]
     ▲                      │                       │
     │                      │ drains                │ drains
     │                      ▼                       ▼
     └────── [rebuffering] ◄── drop bitrate ◄── [low]
              ▲ THE thing to avoid: users tolerate
                lower quality far better than a stall

  Startup: request the LOWEST rung first → playback begins in <1s,
           then climb. Starting high looks better and feels worse.

How it works

  1. HLS or DASH manifest lists renditions and segments; the player (hls.js / Shaka via Media Source Extensions) does the switching.
  2. Start low, climb fast — time-to-first-frame beats initial sharpness.
  3. Prefer dropping quality over stalling. Rebuffering is the metric that correlates with abandonment.
  4. Preload smartly: the next episode's first segments during the end credits; hover previews at the lowest rung only.
  5. Resume position synced to the server every ~10s and on visibilitychange, so any device continues where you stopped.

Trade-offs

ChoiceCost
Short segments (2s)Faster adaptation, more requests
Long segments (10s)Fewer requests, slower reaction
Large bufferResilient, wastes data if abandoned
Start at lowest rungFast start, first seconds look soft

Cross-cutting: DRM licence acquisition before first frame, captions and audio-description tracks as accessibility requirements (8.1), and player telemetry — startup time, rebuffer ratio, average bitrate — as the core quality metrics (7.2).

Interview angle

"The video keeps stalling on mobile. What do you change?"

  • Check the buffer policy first: the player should drop a rung on a draining buffer rather than defending quality.
  • Shorten segment length so adaptation reacts faster, and cap the maximum rung on small screens where 4K is invisible anyway.
  • Verify with rebuffer ratio in telemetry, not by watching it once on a good connection.

Recap

  • Keep the buffer full; quality is the variable you trade to do it.
  • Start at the lowest rung for a sub-second first frame, then climb.
  • Rebuffer ratio, not resolution, is the metric users actually feel.