Why Netflix Rebuilt Its Video Pipeline as Microservices

Netflix's video processing pipeline has been operating since the streaming service launched in 2007. Over that time, it has grown from simple SDR standard-definition encodes to 4K and HDR content, shifted from centralized linear encoding to distributed chunk-based processing, and adopted optimizations like per-title and per-shot encoding. The pipeline has also been extended beyond streaming delivery to support studio and content-development workflows.

That evolution came with cost. By 2018, the third-generation platform, known as Reloaded, had become a bottleneck. The Encoding Technologies (ET) and Content Infrastructure and Solutions (CIS) teams responded by building Cosmos, a microservice-based computing platform designed for workflow-driven, media-centric processing. This article outlines the move from Reloaded to Cosmos and the architectural principles behind the new design.

The Limits of the Reloaded Monolith

Reloaded, developed starting in 2014, was built as a single monolithic system to handle one primary use case: converting studio mezzanine files into compressed streaming assets. It served well for years, but as new use cases were added, its structural constraints became increasingly difficult to work around.

Three problems stood out:

  • Coupled functionality: Reloaded consisted of worker modules plus an orchestration module. Adding a new module and wiring it into orchestration required substantial effort, pushing developers to extend existing modules rather than create new ones. Video quality calculation, for example, was embedded inside the video encoder module, making it nearly impossible to recompute quality without re-encoding.
  • Monolithic structure: Modules often lived in the same repository, leading to unintended code reuse across what should have been strict boundaries. That coupling slowed development and forced modules to be deployed together.
  • Long release cycles: Because everything deployed jointly, teams adopted a "release train" model: every two weeks a snapshot of all modules became a release candidate, then underwent about two weeks of exhaustive testing. Depending on when a change landed, it could take between two and four weeks to reach production.

As functionality grew, feature contribution rates dropped. Promising ideas were abandoned because outsized effort was needed to overcome architectural limitations. The platform that had enabled innovation was now impeding it.

Cosmos: A Platform for Media Microservices

In 2018, CIS and ET began developing Cosmos as the next-generation platform. The goal was to retain Reloaded's scalability and stability while dramatically increasing flexibility and development velocity. Cosmos was designed as a computing platform for workflow-driven, media-centric microservices.

The microservice architecture provides strong decoupling between services. Per-microservice workflow support simplifies complex media workflow logic, and abstractions let algorithm developers focus on video and audio signal processing rather than infrastructure concerns.

Defining Service Boundaries

In a microservice architecture, the first and most important design step is identifying service boundaries. In the Netflix pipeline, media assets pass through processing steps such as analysis and transformation as they travel from creation to ingest to delivery. The team examined these steps, grouped them into domains, and designed services around those domains.

To illustrate the difference in granularity, consider how Reloaded's video encoding module bundled five steps into one module:

  1. Divide the input video into small chunks.
  2. Encode each chunk independently.

Separating Concerns in the Video Pipeline

With the above reframing, the Cosmos team split what was monolithic video processing into discrete microservices. In the earlier codec and packaging pipeline, a single job would, for example, split a mezzanine into chunks, encode each chunk, and then assemble the results. But from a functional perspective, that job actually performs two distinct operations: encoding video and measuring its quality. The chunking and assembly steps exist only for latency and resiliency reasons; they are implementation details of the encoding process, not standalone business capabilities.

Cosmos therefore defines a Video Encoding Service (VES) and a separate Video Quality Service (VQS). VES wraps the chunked-encoding workflow, including the internal chunking and final assembly, behind its API. VQS independently computes quality scores using VMAF. These are the first two of several video services that now comprise the pipeline.

The Video Services

The broader video processing pipeline was decomposed into the following core services, each exposing a single, well-defined function:

  • Video Inspection Service (VIS): Accepts a mezzanine file and extracts metadata from its various layers for downstream consumers. It also flags invalid or unexpected metadata and routes actionable feedback back to the upstream team.
  • Complexity Analysis Service (CAS): Analyzes a mezzanine to understand its content complexity, since the optimal encoding recipe is content-dependent. CAS delegates to VES for pre-encoding and to VQS for quality evaluation, saving the results to a database for reuse.
  • Ladder Generation Service (LGS): Creates complete bitrate ladders for a given encoding family (e.g., H.264, AV1). It fetches the complexity data from CAS and runs optimization algorithms to produce encoding recipes. This is the service that houses Netflix's per-title, per-shot, and mobile encoding innovations. Wrapping this logic into its own service decouples the ladder optimization algorithms from the complexity data management performed by CAS, which is intended to allow greater freedom for experimentation.
  • Video Encoding Service (VES): Takes a mezzanine and an encoding recipe as input and produces an encoded video. The recipe specifies output properties such as format, resolution, and bitrate. Options permit fine-tuning for latency and throughput per use case.
  • Video Validation Service (VVS): Validates an encoded video against a list of expectations, including both the recipe-specified attributes and codec spec conformance requirements. Any discrepancies are flagged in the response to alert the caller.
  • Video Quality Service (VQS): Computes the VMAF quality score of an encoded video by comparing it with the source mezzanine.

Orchestration by Business Need

These video services are the functional building blocks, but they are orchestrated differently to meet the two main demands on the pipeline: producing assets for member streaming and generating assets for studio operations. Each use case is handled by its own dedicated workflow orchestrator, allowing the orchestration to be tailored to distinct business requirements.

The Streaming Workflow Orchestrator is responsible for assets destined for the content delivery network, which may be watched millions of times. It therefore uses nearly the entire suite of video services: VIS to detect and reject non-conformant mezzanines, LGS to optimize encoding recipes, VES for encoding, and VQS for quality measurement, with that quality data feeding downstream analytics and monitoring. A number of services outside the dedicated video services are also invoked here: audio and timed-text services generate their respective assets, and packaging services containerize everything for streaming.

The Studio Workflow Orchestrator serves a different purpose. Assets like marketing clips and daily production proxies tend to be latency-sensitive. For instance, a production team member may be waiting for a proxy to approve a shot list for the following day. The orchestrator therefore targets fast turnaround and only calls the core processing services. It invokes VIS to extract metadata and VES with predefined recipes. The studio side is also the only consumer of certain features, including forensic watermarking and timecode/text burn-in.

Press enter or click to view image in full size

Migration status and early returns

The new pipeline has been running in production alongside the legacy Reloaded system for several years. The team completed migrating all required functionality from Reloaded, gradually shifted traffic over one use case at a time, and finished the full switchover in September 2023.

Even at this early stage, the platform's benefits are visible, especially in how quickly new features can be delivered. A key example is the launch of the Advertising-supported plan in November 2022. Ad creatives presented media formats and content requirements that were quite different from the movie and TV mezzanines the pipeline was built for. Thanks to Cosmos's modularity and improved developer productivity, the pipeline was iterated on quickly to keep pace with the evolving Ad requirements and support the successful product launch.