Design a Video Streaming Platform (Netflix) — Cheat Sheet

A video streaming platform must ingest large video files, transcode them into dozens of resolution/codec combinations, distribute the encoded segments to a globally distributed CDN, and serve them to clients that adapt quality in real-time based on available bandwidth. Beyond delivery, it needs a content catalog, user profiles, watch history, and a recommendation engine — all at the scale of hundreds of millions of concurrent streams.

• ✓Content creators (studios) upload raw video files for processing
• ✓Users can browse a content catalog (title, genre, cast, synopsis, thumbnail)
• ✓Users can play a video and have it adapt quality based on their bandwidth
• ✓Resume playback from where the user left off across devices
• ✓Search the catalog by title, genre, or cast
• ✓Personalised recommendations on the home screen

• ✓Concurrent streams (peak): 15M streams
• ✓Avg bitrate per stream: ~5 Mbps (mix of SD/HD/4K)
• ✓Total peak bandwidth: 15M × 5 Mbps = 75 Tbps
• ✓Catalog size: ~15,000 titles; each transcoded into ~50 files
• ✓Storage per title (all resolutions): ~100 GB average
• ✓Total catalog storage: 15,000 × 100 GB = 1.5 PB

• ✓Studio Upload Portal — Web interface for studios to upload raw video files. Uses chunked, resumable multipart uploads directly to object storage (S3). Publishes an UploadCompleted event to Kafka on success.
• ✓Transcoding Pipeline — Distributed pipeline of worker nodes that takes the raw video and produces multiple renditions (resolutions × codecs × HDR variants). Each rendition is segmented into small HLS/DASH chunks. Workers are horizontally scalable and GPU-accelerated.
• ✓Content Delivery Network (CDN) — Netflix Open Connect Appliances (OCA) — dedicated CDN servers co-located in ISP networks worldwide. During off-peak hours, OCAs pre-fetch popular content from origin. At streaming time, the client is directed to the nearest OCA for sub-millisecond-latency segment fetches.
• ✓Content Catalog Service — Stores metadata about each title: synopsis, cast, genres, maturity rating, available languages, thumbnail URLs, and manifest URLs. Backed by a relational DB (read replicas) and cached aggressively in Redis. Powers both the browse API and the search index.
• ✓Playback Service — Issues a signed playback token after validating the user's subscription, device limit, and DRM entitlement. Returns the CDN URL of the adaptive manifest (M3U8/MPD) for the requested title. The client then fetches segments directly from CDN.
• ✓ABR Streaming Client — The video player (HLS.js on web, ExoPlayer on Android, AVPlayer on iOS) downloads the manifest and then selects the appropriate quality rendition per ~4-second segment based on measured download throughput, buffer occupancy, and a buffer health target.

• ✓Third-party CDN vs proprietary CDN (Open Connect) → Proprietary CDN (Open Connect): Netflix's traffic volume makes transit costs prohibitive via commercial CDNs. Co-locating appliances inside ISPs eliminates transit, allows proactive cache fill during off-peak, and gives Netflix direct control over OCA steering decisions.
• ✓HLS vs DASH for adaptive streaming → Both — HLS for Apple devices, DASH elsewhere: Safari and iOS require HLS due to Apple's platform restrictions. DASH is an open standard with better tooling on Android and Smart TVs. Netflix produces both manifests from the same segment files, keeping storage overhead minimal.
• ✓Single transcode job vs parallel chunk encoding → Parallel chunk encoding: A 2-hour film encoded sequentially can take 8+ hours. Splitting into 10-minute chunks processed in parallel across GPU workers reduces this to under 30 minutes — essential for meeting the 24h SLA from upload to availability.
• ✓Real-time vs batch recommendation generation → Batch (nightly) with real-time watch signal ingestion: Running a matrix factorisation model at request time for 220M users is computationally infeasible. Nightly batch produces per-user recommendation lists. Real-time signals (current session watch history) adjust ordering at serve time with lightweight rules.
• ✓PostgreSQL vs NoSQL for content catalog → PostgreSQL (relational): Catalog data is highly relational (titles, seasons, episodes, cast, genres). Complex join queries are needed for the editorial team's CMS. PostgreSQL with read replicas and a Redis cache layer handles the catalog read load comfortably without NoSQL complexity.

• ✓Interviewers expect you to know the transcoding pipeline. Parallelise by splitting the video into chunks — this is the key insight that unlocks the 24h SLA.
• ✓ABR streaming is a standard follow-up. Know the HLS manifest structure (master playlist → rendition playlist → segment files) and explain why the client — not the server — selects quality.
• ✓Open Connect / CDN co-location is a differentiator answer. Most candidates say "use CloudFront." Knowing WHY Netflix built its own CDN (transit cost, proactive fill) signals senior-level depth.
• ✓Separate the upload pipeline from the streaming path clearly. Studios upload to origin; end users stream from CDN. The origin is never on the hot path for a streamed title.
• ✓For recommendations, avoid over-engineering. State the problem (collaborative filtering), name the algorithm (ALS matrix factorisation), describe the batch pre-computation, and explain that results are cached. That's enough for most interviews.
• ✓DRM is a common extension. Know: content encrypted with AES; decryption keys served by a licence server after entitlement check; keys bound to device certificate (Widevine / FairPlay).