Netflix Streaming Service Design

In 2016, Netflix launched offline viewing—the ability to download content to mobile devices for watching without internet connectivity. What seems like a simple feature required solving complex problems across licensing, DRM, storage management, and sync.

Offline viewing addresses crucial user scenarios:

• Travel: Planes, trains, areas with poor connectivity
• Data Caps: Many regions have expensive or limited mobile data
• Commute: Subway tunnels and remote areas without coverage
• Cost Sensitivity: Download on WiFi, watch on mobile without using data

For Netflix's global expansion, especially in markets like India where mobile data is precious because of cost, offline viewing was essential for competitive viability.

This page explores the complete offline architecture—from download initiation through DRM protection to playback and sync—and the unique engineering challenges of building offline-first features into a streaming platform.

Not all Netflix content can be downloaded. Content licensing introduces constraints that fundamentally shape the offline feature's design.

Technical Enforcement:

Licensing constraints are enforced through multiple mechanisms:

1. API Response — Download eligibility returned with content metadata. UI hides download button for ineligible content.

2. License Server — DRM licenses issued with expiration timestamps. Client enforces; can't play after expiration.

3. Periodic Check-in — Devices must periodically connect online to verify account status. Prevents using downloads after account cancellation.

4. Device Registration — Account tracks registered download devices. Deregistering a device invalidates its downloads.

5. Audit Logging — All download events logged for rights holder auditing. Studios may request download metrics.

The download system is a sophisticated client-side component that manages content acquisition, storage, and availability while handling the unreliable nature of mobile networks.

Chunked Download Strategy:

Content is downloaded in the same segment format used for streaming (typically 2-10 second chunks). Benefits:

• Resume Capability — If download interrupts mid-segment, only that segment is re-downloaded
• Parallel Downloads — Multiple segments downloaded simultaneously (typically 3-5 parallel connections)
• Storage Efficiency — Same files used for streaming can be cached; no duplication
• Quality Adaptation — Can switch quality mid-download if storage runs low

Download Quality Selection:

User settings:
├── Download Quality: Low / Standard / High / Auto
├── WiFi Only: Yes / No
└── Storage Limit: e.g., 10 GB maximum downloads

Auto quality logic:
├── Check available storage
├── Check user's preferred quality
├── Check content's available qualities
├── Select highest quality that fits constraints
└── Fallback to lower quality if needed

Bandwidth Management:

• Download manager respects user's bandwidth preferences
• Throttles downloads when streaming is active (streaming priority)
• Pauses downloads on cellular if WiFi-only is set
• Resumes automatically when conditions met (WiFi connected, app foregrounded)

Offline content presents unique DRM challenges. The device must protect content without being able to phone home to verify authorization in real-time. This requires a fundamentally different approach to licensing.

Security Levels and Offline:

DRM security levels impact offline capabilities:

L1 (Hardware DRM):

• Key handling in hardware TEE (Trusted Execution Environment)
• Required for HD/4K offline on most devices
• iOS, most Android flagship phones, some tablets

L3 (Software DRM):

• Key handling in software (more vulnerable)
• Limited to SD quality for offline
• Older Android devices, some tablets, emulators

Offline License Acquisition Flow:

1. [Client] Request download for Title X
2. [API] Return manifest + license server URL
3. [Client] Send license request with:
   - Device certificate (proves device identity)
   - Content ID
   - Requested license type: PERSISTENT
4. [License Server] Verify:
   - Account has download rights for this content
   - Device hasn't exceeded device limit
   - Content is available in user's region
5. [License Server] Return encrypted license:
   - Decryption keys for content
   - Expiration timestamp
   - Playback rules (quality limit, renewal window)
6. [Client] Store license in secure storage
   - Protected by device keychain/keystore
   - Encrypted at rest

Mobile devices have limited storage, and downloaded video content is large. Netflix must carefully manage storage to provide a good experience while respecting device constraints.

Smart Downloads:

One of Netflix's most popular features: Smart Downloads automatically manages series watching:

How It Works:

1. User downloads Episode 1 of a series
2. User finishes watching Episode 1
3. System automatically:
   • Deletes Episode 1 (watched, no longer needed)
   • Downloads Episode 2 (next in sequence)
4. Repeat as user progresses through series

Benefits:

• User always has next episode ready
• No manual download management needed
• Storage stays bounded (only 1-2 episodes per series)
• Works offline—downloads triggered when online connection available

Technical Implementation:

On play completion event:
├── Mark current episode as watched
├── Check if more episodes exist in series
├── If yes:
│   ├── Queue next episode for download
│   ├── Schedule deletion of current episode
│   └── Deletion happens after download completes
└── If no:
    └── Delete current episode (series complete)

Eviction Policies:

When storage limit is reached, Netflix must choose what to delete:

1. Expired Content — Always deleted first (unusable anyway)
2. Watched Content — User has already seen it
3. Oldest Downloads — Least recent downloads least likely to be watched
4. User Preference — Ask user which content to remove if automated eviction insufficient

Downloaded content exists on a device disconnected from Netflix's servers. When the device reconnects, various state must be synchronized. This creates classic distributed systems challenges.

Conflict Resolution:

When offline viewing and online viewing happen on different devices, conflicts can arise:

Scenario: User downloads Episode 1-5 on tablet, watches Episode 3 offline. Meanwhile, on phone (online), they watch Episode 4.

Conflict: Where is the 'current position' in the series?

Resolution Strategy:

1. Last Writer Wins — Most recent viewed episode becomes 'current'. Offline tablet syncs, server sees Episode 3 was watched after Episode 4 (by timestamp). Episode 3 becomes current position.

2. Max Progress Wins — Alternative: highest watched episode wins. Episode 4 > Episode 3, so Episode 4 remains current.

3. Netflix Approach — Generally max progress with nuance. If offline viewing is 'more recent' by wall-clock time, it takes precedence. UI handles edge cases gracefully (showing both positions in some cases).

Sync Protocol:

On connectivity restoration:
1. Send local state diff to server:
   - Viewing history updates (episodes watched offline)
   - Progress updates (current position per title)
   - Download completions/failures

2. Receive server state:
   - Account status (still valid?)
   - License renewals available
   - Content availability changes
   - Cross-device viewing updates

3. Reconcile conflicts:
   - Server provides canonical merged state
   - Client updates local state to match
   - UI reflects current position per reconciliation

4. Background sync:
   - Continue license renewals
   - Queue Smart Download processing
   - Update recommendation data

The offline playback experience must match the quality of online streaming while working entirely from local storage. This requires careful engineering of the player and content pipeline.

Downloaded Content Package:

A complete download includes multiple components:

Downloaded Package:
├── Video Segments
│   ├── video_720p_0001.mp4
│   ├── video_720p_0002.mp4
│   └── ... (hundreds of segments)
├── Audio Tracks
│   ├── audio_english_0001.mp4
│   ├── audio_spanish_0001.mp4
│   └── ... (per-language segments)
├── Subtitles
│   ├── subtitles_english.vtt
│   ├── subtitles_spanish.vtt
│   └── ... (per-language files)
├── Manifest
│   └── local_manifest.json (segment mapping)
├── Metadata
│   ├── title_info.json (title, synopsis, runtime)
│   ├── chapter_markers.json (skip intro timestamps)
│   └── artwork.jpg (display images)
└── License
    └── offline_license.bin (encrypted DRM license)

Player Integration:

The offline player is the same player used for streaming, with different content source:

• Online Mode: Fetches segments via HTTP from CDN
• Offline Mode: Reads segments from local filesystem

The abstraction layer (content source) is swapped; the rest of the player (decode, render, controls) remains identical. This ensures feature parity between modes.

Seek Performance:

Seeking in offline content is typically faster than online:

• No network latency for fetching new segments
• Local SSD/flash storage has low access latency
• Segment already decrypted (license cached)

Typical seek time: 200-500ms (vs. 500-2000ms online depending on network).

Offline viewing involves numerous edge cases that must be handled gracefully. Poor error handling is the difference between a beloved feature and a frustrating one.

Error Recovery Strategies:

Download Failures:

Playback Failures:

Graceful Degradation:

When partial failures occur, Netflix degrades gracefully:

• Missing subtitle language: Show download without that language, offer download
• Missing audio dub: Show in original language with subtitles
• Partial download: If first X episodes complete, make those available while continue downloading rest
• License renewal failure: Allow continued playback until hard expiration

Netflix's offline viewing is a masterclass in handling offline-first functionality within an otherwise connected system. The key principles apply to any system requiring offline capability.