Designing Netflix (Video Streaming Frontend System Design)

pranav m

walmart

medium

0completed

R — Requirements

In interviews, this is where you define scope before jumping into architecture.

Functional Requirements

1. Content Browsing

Users should be able to:

View categorized rows (Trending, Popular, Continue Watching)
Scroll horizontally within rows
Scroll vertically across sections
Search movies and TV shows
Filter by genre, language, and year

2. Personalization

Show personalized recommendations
Maintain “Continue Watching” list
Display recently viewed content
Track watch history

3. Video Playback

Stream video content
Play, pause, seek
Adaptive quality switching
Subtitles and audio language selection
Fullscreen playback

4. User Account

Login / Logout
Multiple profiles
Parental controls
Manage subscription

5. Device Support

Web browsers
Mobile browsers
Smart TV browsers (limited capability environments)

Non-Functional Requirements

1. Internationalization (i18n / L10n)

Multi-language UI
Region-specific content catalog
Subtitle & audio language selection
RTL support when required

2. Offline Functionality

Resume playback after reconnect
Persist Continue Watching locally
Cache thumbnails and metadata
Optional offline download support

3. Security Considerations (XSS, CSRF)

Prevent XSS in dynamic metadata
Secure authentication tokens
Protect sessions from hijacking
DRM protection for streaming
Signed streaming URLs

Keyboard navigation
Screen reader support
Subtitle customization
Focus management for TV navigation

5. Performance Expectations

Fast homepage initial render
Smooth scrolling across content rows
Low buffering time during playback
Adaptive bitrate streaming
Minimal layout shift

C — Components

Now lets focus on component hierarchy, state ownership, and communication.

Components Tree

File tree format

App
 ├── BillboardSlider
 │    └── FeaturedCard (VideoCard)
 │
 ├── VideoList
 │    ├── SearchBar
 │    ├── FilterOptions
 │    ├── SortOptions
 │    └── VideoCard[]
 │
 ├── RecommendedRow
 │    └── VideoCard[]
 │
 ├── VideoCard (Shared Component)
 │    ├── Thumbnail
 │    ├── Title
 │    ├── Rating
 │    ├── HoverPreview
 │    └── AddToList
 │
 └── VideoPlayer
      ├── VideoStream
      │    ├── Buffer
      │    └── Resolution
      │
      ├── PlayerControls
      │    ├── PlayPause
      │    ├── SeekBar
      │    ├── VolumeControl
      │    ├── SubtitleSelector
      │    └── QualitySelector
      │
      └── NextUpPanel
           └── NextVideoCard

State Management Strategy

For a Netflix-scale app, state is separated into three layers.

Local Component State

Used for short-lived UI behavior:

Search input value
Hover preview visibility
Player controls (play/pause, volume, fullscreen)
Subtitle and audio selection during playback

If the state belongs to one component or screen, keep it local.

Server State (API Data)

Handled using React Query / RTK Query.

Examples:

Video lists and recommendations
Search results
Video metadata
Continue Watching progress sync
Streaming URLs and subtitle tracks

Responsibilities include caching, background refetching, and request deduplication.
Server data should not live in Redux.

Global Application State (Redux)

Used for cross-app shared state.

Authentication

Logged-in user
Session status
Subscription plan

Profile

Selected profile
Language and maturity settings

Playback

Current playing video ID
Playback progress for resume
Mini-player / picture-in-picture state

App Configuration

Region and language
Feature flags / A/B testing
Device capabilities (TV vs mobile vs web)

State Ownership Summary

State	Location
Video lists	Server state
Search results	Server state
Player controls	Local state
Logged-in user	Global state
Selected profile	Global state
Current playing video	Global state
Playback progress	Global + Server sync

A — Architecture

Now we define the major architectural decisions for the Netflix frontend and why each choice fits a large-scale streaming platform.

1. SSR vs CSR vs SSG

Chosen: Hybrid → SSR + CSR (Streaming pages CSR-heavy)

Area	Rendering Strategy	Why
Landing / marketing pages	SSG	Static and SEO focused
Home / Browse / Search	SSR	Fast first paint + personalization
Player page	CSR	Highly interactive and device-specific

Why this choice

Pure CSR would slow initial homepage load.
Pure SSR is not suitable for video playback and device-specific logic.
Streaming UI is highly interactive and must run mostly on the client.

Hybrid rendering provides fast first paint while keeping the player fully client-driven.

2. SPA vs MPA

Chosen: SPA

Why this over MPA

Seamless navigation between browsing and playback
Preserve playback state while navigating
Avoid full reload during streaming
Smooth transitions between content rows

A full page reload during playback would be unacceptable for user experience.

3. REST vs GraphQL

Chosen: GraphQL Gateway + REST Microservices

Why GraphQL Gateway

Netflix UI needs data from multiple domains:

Recommendations
Continue watching
Search
Video metadata
Subtitles and audio tracks

GraphQL acts as a Backend-for-Frontend (BFF) that aggregates multiple services into a single response.

Frontend → GraphQL Gateway → Microservices

Benefits:

Fewer network calls
Fetch only required fields
Easier support for TV and mobile clients

Why REST still exists internally

Microservices still expose REST APIs:

Simpler service ownership
Easier caching and scaling
Better observability

This hybrid approach is common in large streaming platforms.

4. Transport Protocol (HTTP/1.1 vs HTTP/2 vs HTTP/3)

Chosen: HTTP/2 with HTTP/3 support

Why:

Multiplexing improves loading of thumbnails and metadata
Better performance on mobile networks
Faster connection recovery using QUIC (HTTP/3)

Important for:

Image-heavy home feeds
Global streaming users
Mobile and TV devices

5. Communication Protocols (Streaming)

Streaming is the most critical part of Netflix architecture.

Chosen: Adaptive Streaming using HLS / MPEG-DASH over HTTP

Why not WebSockets

Video streaming is not a realtime chat problem.
It is a high-bandwidth, buffered delivery problem.

Adaptive Bitrate Streaming (ABR)

The player dynamically switches quality based on:

Network speed
Device capability
Buffer health

HLS (HTTP Live Streaming)

Used widely across Apple ecosystem and browsers
Breaks video into small chunks (.ts segments)

MPEG-DASH

Open standard used across many platforms
Similar chunked streaming approach

6. How complete system works

👉 The details above only scratch the surface of streaming architecture. Explaining everything about streaming protocols, transport layers, adaptive bitrate logic, CDN strategy, and DRM flows in a 60-minute interview is quite hard. However, it’s extremely valuable to at least provide an abstract understanding of how these pieces fit together and how they influence frontend design decisions.

For example, you should be comfortable explaining:

When to use HLS vs DASH vs WebRTC
How adaptive bitrate streaming works
How CDN edge delivery affects latency
How signed URLs and DRM secure content
How buffering and quality switching logic impacts the player UI

It’s also useful to understand how frontend state architecture (such as Flux/Redux patterns) can be applied inside the video player. For instance:

Playback state (playing, paused, buffering, ended) can live in a centralized store
Player actions (play, seek, change quality, enable subtitles) dispatch events
The UI reacts to state changes predictably
Analytics and telemetry middleware can hook into player events
Buffer health and bitrate changes can update global playback state

Even if you don’t go deep into implementation, being able to describe the data flow and state transitions inside a video player shows strong architectural maturity.

To prepare properly, I’ve written dedicated deep-dive posts:

Post 1 → Streaming Protocols overview

Post 2 → How Netflix actually uses them end-to-end
Post 3 → How the netflix video player works

D — Data Model (API Interface)

This section explains API contract between frontend and backend

API Interface (Network Contract)

Even though the frontend talks to a GraphQL BFF, we still design the contract using REST-style resource thinking. This keeps APIs predictable, cacheable, and easy to evolve.

Endpoint Design

Method	Endpoint	Purpose
GET	/api/home	Fetch personalized homepage rows + billboard
GET	/api/search	Search movies and TV shows
GET	/api/videos/:id	Fetch video details & recommendations
GET	/api/videos/:id/playback	Fetch signed streaming URLs + DRM info
GET	/api/profiles	Fetch user profiles
POST	/api/profiles/select	Switch active profile
POST	/api/videos/:id/my-list	Add/remove from My List
POST	/api/videos/:id/progress	Update playback progress
GET	/api/users/me/continue-watching	Fetch Continue Watching list
GET	/api/users/me/my-list	Fetch saved videos

Video Response Structure (Frontend-Friendly Payload)

{
  "id": "v1",
  "title": "Stranger Things",
  "thumbnail": "thumb.jpg",
  "duration": 3600,
  "maturityRating": "16+",
  "genres": ["Sci-Fi", "Drama"],
  "progressPercent": 42,
  "isInMyList": true,
  "availableAudio": ["en", "es"],
  "availableSubtitles": ["en", "es", "fr"]
}

Important frontend fields:

progressPercent → Continue Watching bar
isInMyList → instant toggle UI
availableAudio / subtitles → player controls without extra calls

Pagination Contract

Cursor-based pagination for feeds and recommendations.

{
  "data": [...],
  "nextCursor": "xyz123",
  "hasMore": true
}

This works naturally with infinite scrolling rows.

Streaming Contract (How Video Chunks Are Fetched)

Streaming does not download the full video file.
Instead, the player downloads small chunks continuously using HLS / MPEG-DASH.

Step 1 — Fetch Playback Sources

GET /api/videos/:id/playback

{
  "hlsUrl": "https://cdn.netflix.com/movie/master.m3u8",
  "dashUrl": "https://cdn.netflix.com/movie/master.mpd",
  "drmLicenseUrl": "https://drm.netflix.com/license",
  "expiresAt": 17000000
}

These URLs are short-lived signed CDN links.

Step 2 — Player Downloads Manifest File

The .m3u8 (HLS) or .mpd (DASH) file is a playlist of video segments.

It lists available qualities:

360p/index.m3u8
720p/index.m3u8
1080p/index.m3u8

The player now knows all available resolutions.

Step 3 — Each Quality Contains Video Segments

Each quality playlist contains small chunks (~2–6 seconds).

segment1.ts
segment2.ts
segment3.ts

The player continuously downloads the next segment while playing the current one.

This is how it knows what to fetch next.

Step 4 — Buffering & Continuous Fetching

The player maintains a buffer ahead of playback.

While segment 1 plays → preload segments 2–4.

This ensures smooth playback.

Step 5 — Adaptive Bitrate Switching (ABR)

The player monitors:

Network speed
Buffer health
Device capability

If network drops → switch from 1080p → 720p seamlessly by requesting segments from another quality playlist.

Step 6 — Seeking / Jumping

When the user seeks to 40 minutes:

40min / 4sec per chunk ≈ segment 600

Player directly requests:

segment600.ts
segment601.ts

No need to download earlier segments.

Playback Progress Sync Strategy

While watching:

Save progress every 10–15 seconds
Sync on pause or exit
Send progress on tab close (sendBeacon)

When reopening a video:

Fetch last progress
Resume playback automatically

This enables seamless multi-device viewing.

O — Other (Performance, Accessibility, Security)

This section highlights cross-cutting concerns that make the Netflix experience feel fast, inclusive, and secure across web, mobile browsers, and Smart TVs.

Performance

A streaming homepage is image-heavy, scroll-heavy, and interaction-heavy, so performance optimizations are essential.

1. Rendering & Scrolling Performance

Virtualization for rows
- Only render visible rows and cards (react-window / react-virtualized).
- Critical because the homepage can contain hundreds of videos.
Horizontal row virtualization
- Render only visible cards while scrolling sideways.
- Prevents DOM explosion on TV browsers.
Intersection Observer
- Lazy load thumbnails when rows enter viewport.
- Start fetching next rows before user reaches them.

2. Bundle Optimization

Route-based code splitting
- Separate bundles for:
- - Home/Browse
  - Search
  - Video Player (large bundle)
- Player bundle loads only when entering playback.
Component lazy loading
- Hover preview player
- Subtitle editor / settings
- Profile management screens