Design Netflix

Design a video streaming platform like Netflix. Users browse a catalog, and stream high-quality video content on demand across different devices and network conditions.

Capacity Estimation

• Peak concurrent streams: 220M users × 10% active = 22M concurrent streams
• Bandwidth per stream: 4K = 15 Mbps, 1080p = 5 Mbps, 720p = 2.5 Mbps. Average ~5 Mbps
• Total bandwidth: 22M × 5 Mbps = 110 Tbps — this is why CDN is non-negotiable
• Content storage: 1 movie = ~100 GB (raw) × 10 encoding profiles = ~1 TB per title. 15K titles × 1 TB = 15 PB

Architecture

Control Plane (content management)

Content Team
    │
    ▼
[Transcoding Pipeline]
  raw video → encode 10 resolutions → upload to CDN
    ├── H.264 (broad compatibility)
    ├── H.265/HEVC (4K efficiency)
    └── AV1 (best compression, used for 4K+ on supported devices)

Data Plane (streaming)

Client
  │
  ├── [API Service] → metadata, catalog, recommendations
  │
  └── [CDN (Open Connect)] → video chunks
         │
    CDN edge server fetches from S3 origin on cache miss

Open Connect: Netflix's custom CDN with servers inside ISP data centres. This eliminates most transit costs and reduces latency to <20ms for video chunks.

API Design

GET /catalog?genre=action&page=1
GET /titles/{titleId}
GET /titles/{titleId}/manifest  → returns MPD/M3U8 playlist
  (Adaptive bitrate manifest listing all quality levels)

GET /recommendations?userId={id}

GET /playback/resume?titleId={id}&userId={id}
  → { position: 3601, episodeId: "...", deviceId: "..." }

PUT /playback/position
  Body: { titleId, position, episodeId, deviceId }

Database Design

Content metadata (Cassandra + Elasticsearch)

titles: id, name, description, genres[], cast[], rating
episodes: id, title_id, season, episode_number, duration
encoding_profiles: id, title_id, resolution, bitrate, s3_url

User data (MySQL — strong consistency for billing/subscription)

users: id, email, plan, subscription_status
watchlist: user_id, title_id, added_at
watch_history: user_id, title_id, position, last_watched

Recommendations (offline batch job → Redis pre-computed per user)

REDIS: recommendations:userId → List of titleIds

Scaling Strategy

Adaptive Bitrate Streaming (ABR)

Video is encoded into 10-second chunks at multiple quality levels. The client player (adaptive bitrate algorithm) monitors download speed and switches quality levels seamlessly.

1080p chunk → downloads in 2s (target 10s TTL) → buffer healthy → stay at 1080p
1080p chunk → downloads in 8s → buffer dropping → switch to 720p

CDN Preloading

Popular new releases are pre-pushed to all edge CDN servers before release. When 22M subscribers hit play at the same time, they all get it from local CDN — the origin sees zero traffic.

• Own CDN vs third-party CDN: Netflix's Open Connect costs more upfront but saves ~$100M/year in transit fees.
• H.265 vs AV1: AV1 is ~30% more efficient but CPU-intensive to encode. Netflix uses it selectively for 4K.
• Cassandra vs PostgreSQL for catalog: Cassandra handles read-heavy catalog queries at global scale; PostgreSQL is used for user/billing data that needs ACID guarantees.

• Thundering herd on new releases: CDN pre-warming before release
• Video transcoding backlog: dedicated GPU farms for encoding; priority queue for popular titles
• Recommendation latency: pre-compute recommendations daily, serve from Redis

• CDN edge failure: client falls back to next-nearest CDN PoP. Netflix engineers define fallback regions.
• Playback position DB down: player uses local cache and syncs when DB recovers. Slight inconsistency is acceptable.
• Chaos Engineering (Chaos Monkey): Netflix intentionally kills production instances to validate fault tolerance.