Building a Netflix-Scale Streaming Platform

Designing a video streaming platform at Netflix's scale requires decomposing the system into a control plane and a data plane, backed by a global CDN. The control plane handles content ingestion, while the data plane serves user playback requests. Storage is split between metadata stores and time-series databases for subtitles.

Requirements and Capacity

The core in-scope features are content upload by creators, playback across devices (TV, mobile, etc.), title-based search, and subtitle support. Personalized recommendations and billing are explicitly excluded from the initial design.

The system must support 100 million active users. The peak load scenario assumes 75% of users request playbacks simultaneously, with each user averaging 3 videos per day. This yields roughly 3,472 videos watched per second. The playback service needs 150 servers, calculated as (75M × 20ms latency) / 10K concurrent connections per server.

Content ingest is substantial: with 2,500 MB uploaded per minute and 10 resolution/codec combinations to support, the platform must store approximately 36 TB of new content daily.

System Architecture

The high-level design consists of four main components: a CDN for content delivery, a control plane for ingestion, a data plane for playback, and persistent data storage for metadata.

Content Distribution Network (CDN) — Stores video files at edge locations geographically close to users. This minimizes latency during playback and reduces upstream bandwidth demand. Netflix's own Open Connect is a network of customized appliances (OCAs) deployed at ISP sites, storing encoded video and serving playable bits directly to clients.

Control Plane — Handles uploads and content distribution across CDNs. It contains the Content Uploader Service, which ingests creator content and distributes it across CDNs while persisting metadata, and the CDN Health Checker Service, which periodically monitors CDN health and playback quality to drive optimizations.

Data Storage — Persists video metadata (title, description) and subtitle information.

Data Plane — The user-facing component for playback requests. The Playback Service determines which files are needed for a specific title, and the Steering Service selects optimal CDN URLs from which the client should fetch those files.

The request flow is as follows:

  1. Content creators upload video content to the control plane.
  2. Content is distributed to CDNs placed geographically near end users.
  3. CDNs report health metrics and file inventory back to the control plane.
  4. Video metadata and CDN information are persisted to data storage.
  5. A client device requests playback for a specific title.
  6. The Playback Service identifies the required files for that title.
  7. The Steering Service selects the optimal CDN and returns its URLs to the client.
  8. The client fetches the requested files from the CDN.
  9. The CDN serves the files, which are rendered on the client device.

API Endpoints

Three primary REST APIs expose the core functionality:

Video Upload — POST /video-contents/v1/videos with a body containing title, description, tags, category, and the video stream itself.

Video Search — GET /video-contents/v1/search-query/ accepts a user-location query parameter.

Video Streaming — GET /video-contents/v1/videos/ accepts an offset parameter (seconds from the video start) to support seeking and resume.

Data Model Design

Two distinct storage systems handle the data requirements. Video metadata is stored in MongoDB (or similar document store), chosen because metadata reads and updates occur on aggregate documents.

Subtitle data is stored in OpenTSDB, a time-series database built on Cassandra. The subtitle model uses an event-based representation called a Media Document, where each subtitle event occupies a time interval on the video timeline.

This timeline-oriented model aligns with Netflix's NMDB (Netflix Media Database), designed to be a highly scalable, multi-tenant media metadata system serving near real-time queries with high read/write throughput. Its data structure is based on this same "Media Document" timeline concept, where media elements have spatial and temporal properties on a unified timeline.

Control Plane Modules

The control plane handles content ingestion and system health. It comprises three microservices: Content Uploader, CDN Health Checker, and Title Indexer.

Content Uploader

When a content creator uploads a video, the Content Uploader orchestrates a pipeline that segments, encodes, and distributes the content across the CDN.

The upload sequence proceeds as follows:

  1. Raw video content is uploaded and received by the Content_Storage_Service, which segments the file into chunks and persists them to file storage.
  2. The Video_Encoder re-encodes each segment across combinations of codec and resolution.
  3. Encoded segments are stored back in the file storage system.
  4. The Video_Distributor reads the encoded segments, pushes them to CDNs, and persists the resulting CDN URLs in the data store.

Video Encoder

The encoder segments the source file into small chunks, then encodes each chunk in every supported codec-resolution combination. For example, supporting four codecs (Cinepak, MPEG-2, H.264, VP8) and three resolutions (240p, 480p, 720p) yields 12 output variants per video segment. All variants are distributed to the CDN, and the playback API selects the optimal URL based on the client's device type, available bandwidth, and other request parameters.

CDN Health Checker

This service collects health metrics from CDNs and stores them so the data plane can route playback requests to the most suitable CDN based on file availability, health, and network proximity.

  1. A cron job triggers the CDN_Health_Checker_Service.
  2. The service contacts CDNs, retrieves health metrics and related information (including BGP routes).
  3. Results are persisted to the data store for use by the data plane.

Title Indexer

A cron job periodically invokes the Title_Indexer_Service, which reads newly uploaded content metadata from the data store, applies business rules to generate search indexes, and writes them to Elastic Search to enable fast content discovery.

Data Plane Workflows

The data plane processes real-time user requests through two primary workflows: playback and content lookup.

Playback Workflow

When a user requests video playback, the Playback_Service orchestrates several microservices:

  1. The client request arrives at the Playback_Service.
  2. The Authorization_Service is called to verify user entitlement and licensing.
  3. The Steering_Service evaluates the request and selects the optimal CDN URL.
  4. The URL is returned to the client device.
  5. The client streams content from the CDN.
  6. Playback events are published back to the Playback_Service.
  7. The Playback_Experience_Service is invoked to track quality metrics.

Content Lookup Workflow

This workflow handles search requests. The Content Discovery Service (CDS) queries Elastic Search for an exact title match. If found, video details are fetched from the data store and returned. If the title is missing, the CDS calls the Content Similarity Service (CSS) to obtain similar titles, fetches details for those from the data store, and returns them to the client.

Latency Optimizations

To reduce playback latency, CDN information can be cached for use by the Steering Service. Beyond simple caching, however, an asynchronous architecture yields substantial gains. Consider a synchronous implementation of getPlayData() which sequences calls to getCustomerInfo(), getDeviceInfo(), and decidePlayData() across different microservices.

A synchronous model blocks a request-handler thread for the duration of the entire call — it works when latency is acceptable and client volume is low, but scales poorly. An asynchronous model replaces the blocking threads with event loops and worker threads:

  • The request-handler event pool dispatches a worker thread per playback request that sets up the full execution flow.
  • Separate worker threads issue getCustomerInfo() and getDeviceInfo() calls in parallel.
  • Once both responses are ready, a final worker thread bundles them for the decidePlayData() call. Context is passed between threads as messages.

The asynchronous design makes better use of available compute and cuts end-to-end latency by overlapping independent service calls.

Resilience and Failure Handling

Microservice architectures demand solid fallback, retry, and timeout policies. Netflix's tooling addresses these concerns directly:

  • Chaos Engineering: randomly terminating production instances with tools like Chaos Monkey ensures services tolerate instance loss.
  • Failure Injection Testing (FIT): introducing latency or faults into service calls lets teams verify fallback behavior.
  • Hystrix: provides circuit-breaker isolation between services when error thresholds are breached. Retry timeouts, service-call timeouts, and Hystrix timeouts must stay in sync to avoid compounding failures.

Extended Requirement: Text-on-Text Detection

A common streaming issue occurs when burned-in video text and subtitles overlap. To detect this, the existing Media Document schema can be extended to include video media metadata. After running text-in-video detection and subtitle positioning algorithms, the results are persisted as separate indexes. A dedicated Text-on-Text detection application queries those indexes to flag overlaps.

Further Reading and References

The material below collects the primary sources behind the architecture discussion above, drawn from Netflix engineering talks, the Netflix Tech Blog, and Open Connect documentation.

Talks and Videos

Architecture Deep Dives

Data Model and Implementation

Written Analyses