Netflix System Architecture: How Global Video Streaming Works

1. Understanding Netflix

Technically, Netflix is two systems that cooperate. One is a large set of cloud services that sign members in, show them a personalized catalogue, decide what they may watch and on which device, and record what happened. The other is a purpose-built content delivery network that moves the video itself. In 2016 Netflix put it this way: "Essentially everything before you hit play happens in AWS", while everything after is unique to Netflix and delivered by its own Open Connect network .

The engineering problem

• Global video distribution. Open Connect reported 18K+ servers in 6K+ locations in July 2025, either at internet exchanges or inside ISP networks . In 2016 it already carried 100% of Netflix video traffic, over 125 million hours of viewing a day .
• Many kinds of devices. In 2013 the API supported more than 1,000 device types , and the 2012 API redesign was driven by more than 800 of them .
• Variable networks. Members watch over connections whose bandwidth changes minute to minute, which is why Netflix encodes many versions of each title and adapts quality chunk by chunk .
• Personalization. Recommendations influence about 80% of hours streamed .
• Availability. Netflix's internal availability goal was 99.99% in 2013 , and by 2016 it described itself as nearing four nines .
• Operational complexity. By 2015 its microservices architecture saw "hundreds of deploys every day" .

Two planes

The most important idea in this study is the split between a control plane that coordinates the experience and a delivery plane that transports playable video.

Open Connect Appliances "only do the following two things": report their status to the control plane in AWS, and serve content over HTTP/HTTPS when a client asks . Steering, fill decisions and telemetry live in the control plane .

Video bytes do not flow through the services that handle accounts, browsing or recommendations. A play request goes to the cloud; the cloud answers with URLs of appliances; the device then fetches the video directly from those appliances .

Why the split matters

Separating the planes lets each be optimised for a different job. The cloud side is built for change: hundreds of microservices, frequent deployments, regional failover . The delivery side is built for throughput and locality: single-purpose, single-tenant appliances that serve pre-encoded files and hold no member data .

The planes are not independent, though. Netflix's deployment guide states the dependency plainly: "If connectivity to AWS is lost, OCAs will stop serving traffic" . The control plane is what tells clients which appliance to use, so an appliance without it is unusable .

How big, and when

Every scale figure in this study carries its date, because Netflix publishes them irregularly and they change quickly.

Measure — Figure — As of; Open Connect servers — 18K+ in 6K+ locations — July 2025; Open Connect appliances — 14,000+ in 142 countries — data as of 2020; Members modelled by the recommendation foundation model — 300M+ users — end of 2024; Requests per second at the edge needing authentication — over 2.5 million — 2021; Viewing per day — over 125 million hours — 2016

Older posts describe the architecture at the time they were written. This study labels such material Historical and does not assume it is still how Netflix works today.

2. High-Level Netflix Architecture

The diagram below groups Netflix's publicly documented responsibilities into the control plane in AWS and the delivery plane in Open Connect. Use Views to focus on services, infrastructure, data flow or reliability, and Press play to trace a session.

The responsibilities

Responsibility — What Netflix has documented — Evidence; Client applications — Devices send the play request to the Netflix application in AWS, then fetch video from OCAs — Confirmed; Edge and authentication — Zuul is the front door for cloud traffic ; tokens are checked at the edge and replaced with a signed "Passport" identity — Historical; API-facing services — The Netflix API serves sign-up, discovery and playback, fanning a request out to many microservices — Historical; Catalogue and metadata — Streaming metadata and user profiles are documented use cases of the Key-Value abstraction — Confirmed; Personalization — Rows, titles and their order are personalized per profile and device — Historical; Playback coordination — Playback services check authorization and licensing, choose files and request steering — Confirmed; Content preparation — Inspection, encoding, audio, subtitles and packaging before publication — Historical; Open Connect CDN — Appliances report status and serve content — Confirmed; Telemetry and analytics — Event pipeline and warehouse ; Atlas for operational metrics — Historical / Confirmed

Some boxes are conceptual groupings. "Discovery & ranking", for instance, stands for several documented algorithms — page generation, ranking, artwork selection — not one service Netflix has named .

A typical streaming session

• The device resolves a region for its cloud traffic; Netflix described moving to latency-based DNS steering using real-user measurements .
• Requests enter through the Zuul gateway, which authenticates at the edge .
• The home page is assembled from precomputed and real-time results .
• When the member presses play, the request goes to playback services in AWS .
• Those services check authorization and licensing and choose the files that suit the device and network .
• The steering service ranks appliances using what they have reported and returns their URLs .
• The device streams from the top-ranked appliance, usually inside or next to its ISP .
• Playback telemetry flows back to the cloud .

Naming changes over time

Netflix has described the playback tier as "playback application services", "Playback Apps", "Play API" and "PlayAPI" in different years. They are probably the same responsibility under different names, but no source says so outright .

How many regions?

Three statements, three dates, three numbers. All three are recorded rather than reconciled:

• Netflix, 2016–2023. Any member could be served from any of three regions (2016) . A 2023 talk said "currently, we run in three regions" .
• Netflix, July 2025. The Open Connect backbone connects IX sites to 5 AWS regions .
• AWS, undated. An AWS page says Netflix operates actively across four AWS Regions .

These describe different things (where members are served from, versus what the backbone reaches) at different times. This study does not pick one.

What is not on the diagram

Netflix runs far more services than any public diagram shows. The overview includes only responsibilities with published evidence, and the inspector for each box lists its sources. Where a box is drawn dashed, its content is inferred, illustrative or unknown.

3. What Happens When Someone Presses Play?

Pressing play starts a conversation with the cloud and ends with the device pulling video straight from an appliance. Step through it below; each step shows its evidence level.

Who is responsible for what

Stage — Cloud services (AWS) — Open Connect — Client; Before any request — Store what appliances report — Report health, routes, files — —; Eligibility — Check authorization and licensing — — — Send the play request; Configuration — Choose files for device and network; steer — — — —; Delivery selection — Rank appliances, return URLs — — — Receive manifest and URLs; Licensing — Issue short-lived licenses — — — Request a license; Streaming — — — Serve files over HTTP/HTTPS — Fetch segments, adapt quality; Recovery — — — — — Use another ranked appliance; Telemetry — Store and interpret playback telemetry — — — Report events and heartbeats

The documented sequence

Netflix's Open Connect overview gives the core sequence , and a 2025 post restates it :

• Appliances continuously report health, learned routes and file availability to cache control services in AWS.
• The device sends a play request to the Netflix application in AWS.
• Playback services check user authorization and licensing, then choose the specific files based on the device and network conditions.
• The steering service uses cache-control data to pick appliances and generate URLs.
• The client receives rank-ordered URLs and connects to the top-ranked appliance.

The exact order of calls inside the playback tier, the manifest format for on-demand video and Netflix's production bitrate algorithm are not public .

Playback configuration and representations

Every title exists as many pre-encoded renditions; appliances serve them as static files and never transcode on request . For Live, Netflix says the manifest comes from the cloud rather than the CDN so it can be personalized per device , and the live packager hands segment-template metadata to the PlayAPI backend to build client manifests .

Steering

The steering service computes a proximity rank from routes ISPs advertise over BGP and logs a "steering playback manifest" for every request . Its ranking follows a modified BGP best-path selection — most specific prefix, shortest AS path, lowest MED, then geography — among appliances that hold the title and have capacity . The client gets typically three or more ranked appliances .

Licensing

In 2017 Netflix described the device fetching a "Playback Context" with stream URLs, then requesting a license to decrypt the DRM-protected stream . Streaming licenses are short-lived and single-use, each DRM technology has its own microservice, and licensing has no fallback: "If licensing goes down, there is no playback" . Download licenses add stateful business rules and can persist on the device .

Adaptive bitrate, buffering and recovery

Netflix describes adaptive streaming as choosing a quality for each chunk based on network and device conditions, and frames the trade-off between aggressive quality and rebuffer risk as a credit-assignment problem . It also uses predictive caching on the device, storing part of a title a member is predicted to play before they press play, which substantially cut start-up wait (2018) . In 2025 it was rolling out app-informed pacing, where the bitrate algorithm tells the transport how fast it needs to send .

A simplified picture of the exchange. Field names are invented for explanation; they are not Netflix's API.

`` POST /play { title, profile, device capabilities, network hints }

200 OK { renditions: [ { codec, resolution, bitrate }, … ], servers: [ "oca-1 (top ranked)", "oca-2", "oca-3" ], license: "request separately, per DRM system" } ``

In browsers, Netflix's JavaScript player picks HTTP servers and fails over using Media Source Extensions, and handles DRM through Encrypted Media Extensions .

What is not documented

• No Netflix-owned source found names PlayReady or FairPlay , and the license protocol and key hierarchy are not documented .
• It has not said what the steering service's internal name "CODA" stands for .
• Its production ABR algorithm and buffer thresholds are not public .

4. Netflix Open Connect CDN

Open Connect is the global network that delivers Netflix shows and movies to members . Netflix began building it in 2011 and announced it in 2012 ; before that it relied on independent CDNs .

Why Netflix runs its own CDN

Netflix gives two reasons . As it became a large share of ISP traffic it needed to work with ISPs directly. And a Netflix-specific design allowed a "proactive, directed caching solution" that cuts upstream demand "by several orders of magnitude" compared with demand-driven CDNs. Netflix also says third-party CDNs "were doing a great job", but its knowledge of what members watch let it place "the right file … on the right server at the right time" .

Two ways to deploy an appliance

• At internet exchanges. Netflix places appliances in IXP locations and interconnects with ISPs through settlement-free public or private peering . It owns these and pays its own power and colocation . In 2021 that meant more than 80 IXP locations in over 25 countries .
• Embedded in ISP networks. Netflix gives appliances free to qualifying ISPs, which supply power, space and connectivity and control which customers reach them . In most cases the ISP takes ownership . More than 1,000 ISPs had installed them by 2021 .

What happens when an appliance cannot serve

If content is not on the embedded appliance, the request goes to the closest Netflix content site via peering, or via transit if there is no peering . If one embedded site fails, traffic moves to a second; if both fail, Netflix IX appliances serve it .

The appliances

Open Connect Appliances (OCAs) are cache appliances built from commodity PC components in custom cases . They temporarily store encoded video and images and serve them over HTTP/HTTPS; they store no viewing history, DRM information or member data .

Size — 2U — 2U; Raw storage — up to 120 TB — up to 60 TB; Throughput — ~200 Gbps — ~80 Gbps; Intended for — IX sites and larger embedded ISPs — smaller ISPs and emerging markets

Figures from Netflix's current appliance page . Very large ISPs also get flash-based appliances once a site passes a size threshold .

The software is FreeBSD-CURRENT, NGINX and the BIRD routing daemon . BIRD collects the ISP's routes and shares them with the control system in AWS . Software ships as a single image with automatic fallback, and upgrades avoid peak hours . A failed drive is disabled and the appliance carries on; content storage "fails in place" with no RAID . Appliances are single-purpose and single-tenant, with serving and management kept apart .

Per-server throughput has risen from 8 Gbps in 2012 to over 90 Gbps in 2016 , with first-server milestones of 400 Gb/s in 2021 and 800 Gb/s in 2022 using encryption offloaded to the network card . A team of about ten maintains the appliance software and merges from FreeBSD-current every three weeks .

Content placement

For delivery, popularity is bytes streamed from a file divided by its size, smoothed over several days and computed per region . In 2016 most clusters moved from ranking whole titles to ranking individual files, reaching the same caching efficiency with half the storage . High-traffic sites use high-throughput servers for popular content and high-capacity servers for the tail; popular titles are replicated on more servers . Within a cluster, content is spread by consistent hashing, with a two-ring scheme for mixed hardware .

Appliances at one site form a "manifest cluster". In a two-appliance cluster about 40% of each one's storage holds the same popular content and the rest is unique .

Netflix sources disagree on catalogue coverage. A 2021 paper says each deployment "stores nearly all of the Netflix catalogue"; the 2025 guide says each appliance stores "a portion", generally less than the regional library. One describes a site and the other an appliance, so this study does not claim that every appliance holds the full catalogue .

Fill and refresh

Appliances use push fill: they fill in a daily off-peak window agreed with the ISP, 12 hours from 2AM to 2PM local time, shiftable by two hours . Netflix can do this because it can "predict with high accuracy what our members will watch and what time of day" .

Appliances know nothing about each other or about popularity; the control plane in AWS does . Each appliance fetches a manifest of what it should hold and requests the difference from a ranked list of sources: first peers in its cluster, then other tiers, then S3 directly . Urgent titles, such as day-of-broadcast episodes, can be filled outside the window . A 2016 example: files cross to Australia once, off-peak, and are then replicated to appliances inside ISP networks .

New appliances arrive pre-filled, burn-in fill takes about two days, and an appliance serves nobody until its checks pass .

Steering and BGP

Embedded appliances are "directed caches": an appliance serves only client IPs its ISP advertises to it over BGP . Routes it learns reach the control plane about every five minutes . Steering then applies a modified BGP best-path selection , with Netflix adding +0 to the MED for embedded appliances, +50 for private interconnects and +100 for public peering . Netflix peers as AS2906, and embedded appliances use AS40027 . It ignores BGP communities from partners .

Reducing transit

Open Connect aims to localize traffic and minimise what goes over transit providers . By handing traffic directly to the ISP, it lets ISPs avoid transit charges and international backhaul; Netflix estimated embedding ISPs saved about $1.2B in 2020 . Fill runs off-peak on capacity ISPs build for peak anyway . Netflix does not charge ISPs for any of this . When embedded appliances and peering are combined, peering mainly carries backup, fill and long-tail titles .

Traditional CDN vs Netflix Open Connect

Editorial comparison. The left column describes common commercial CDN practice in general terms; the right column is sourced. It compares operating models, not performance.

Who uses it — Many customers share it — One tenant: Netflix; How caches fill — On demand, when a user asks — Pre-positioned off-peak from predicted demand; Where caches sit — The provider's points of presence — Inside ISP networks and at internet exchanges; How clients are routed — Often DNS or anycast — URLs ranked by a control plane in AWS; On a cache miss — Fetch from the origin — Closest Netflix site via peering, else transit; Who pays — The content owner pays the CDN — Netflix funds it; free to ISPs

Live

Live content broke the pre-positioning model. Netflix calls Open Connect "more of a distributed origin server" for on-demand video . For Live it extended NGINX proxy caching, added millisecond-grain caching and built a Live Origin in AWS that only designated nodes may fill from .

Open questions

• The current split of traffic between embedded and IX delivery is not published; the only figure found is from 2016 .

5. Content Ingestion and Video Encoding

Everything in this chapter happens before anyone presses play. By the time a member chooses a title, every rendition they might need already exists and is on its way to the appliances .

Why so many encodings

Netflix pre-encodes each title at several bitrates so the client's adaptive streaming can pick the best one for the member's bandwidth and device . In 2015 that meant codec profiles from VC1 to HEVC and quality levels from 100 kbps to 16 Mbps .

Spending bits where they matter

• 2010: one ladder. The first H.264 encodes used one fixed bitrate ladder for the whole catalogue. Grainy content still looked blocky at the top 5800 kbps rung, while cartoons did not need anywhere near it .
• 2015: per-title encoding. Each title gets its own ladder, chosen from trial encodes by finding the best bitrate–quality trade-offs . One BoJack Horseman episode reached 1080p at 1540 kbps; Orange Is the New Black's top rung fell 20% .
• 2018: shot-based dynamic optimizer. Each shot is encoded at many resolutions and quality settings and scored with VMAF, then the best combination is assembled . Against the best fixed-quality encode it saved 17.1% on average, in tests with VP9 on ten titles .
• 2020–2023: premium formats. Optimized 4K encodes halved the average top bitrate and cut rebuffers by over 65% . By June 2023 the whole HDR catalogue was optimized, using 58% of the storage of the fixed ladder .

Codecs over time

When — Codec milestone; 2007 — H.264/AVC becomes Netflix's primary format; 2015 — Profiles: VC1, AVC Baseline, AVC Main, HEVC; 2016 — AVC High and VP9 mobile encodes, first for downloads; Feb 2020 — AV1 on Android, 20% more efficient than VP9; Nov 2021 — AV1 on TVs; Mar 2025 — AV1 with HDR10+; Jul 2025 — AV1 film grain synthesis in production; Dec 2025 — AV1 carries about 30% of all Netflix streaming, second to AVC

AV1 sessions in Netflix's 2025 data used a third less bandwidth than AVC and HEVC, with 45% fewer buffering interruptions .

The pipeline today

From 2021, Netflix described its media platform Cosmos: an API layer, a workflow rule engine and serverless functions packaged as Docker images, talking asynchronously through a priority queue . The video pipeline finished moving onto Cosmos microservices in September 2023 .

• Inspection (VIS) rejects non-conformant or low-quality sources . IMF is the preferred delivery format, and Netflix asks for redelivery rather than repairing bad sources .
• Complexity analysis (CAS) and ladder generation (LGS) decide the ladder per encoding family .
• Encoding (VES) splits, encodes in parallel and reassembles, with one function per codec .
• Validation (VVS) and quality (VQS) check each encode; VQS computes VMAF .
• Audio, timed text and packaging containerize the assets for deployment to the CDN .

Packaging wraps streams in the CMAF subset of ISOBMFF, adds Common Encryption, and provides A/V sync and random access . Output goes to a custom object store on S3 , and the packager gets its keys from Netflix's security backend .

Where encoding runs

Year — Compute; 2015 — EC2 Linux instances, using an internal "spot market" of idle reserved instances that peaked above 12,000 a day; 2018 — A compute farm of "tens of thousands of EC2 instances"; 2021 — Cosmos functions on the Titus container platform, using millions of CPU-hours a day; 2024 — Encoding containers bin-packed onto EC2 instances by CPU and memory "shape"

That encoding still runs on EC2 today is a reasonable reading of the 2024 posts, but no post states it directly .

Quality measurement

VMAF, built with the University of Southern California, combines several quality metrics to predict how viewers would rate a video. Netflix open-sourced it in 2016 . The project is now under a BSD+Patent licence and is still updated .

Reliability of the pipeline

In 2015 Netflix reported encode reliability of 99.99% or better for sources that passed inspection, with each chunk verified after encoding .

Live, for contrast

Live video is encoded in real time with AWS Elemental MediaConnect and MediaLive, in AVC and HEVC with 2-second segments over HTTPS .

6. Cloud and Microservices Architecture

Why Netflix moved

In August 2008 a major database corruption stopped Netflix shipping DVDs for three days . The lesson it drew was to move away from vertically scaled single points of failure towards "highly reliable, horizontally scalable, distributed systems in the cloud" . It chose AWS for "the greatest scale and the broadest set of services and features" , and says cost was not the main reason, although cloud cost per streaming start ended up a fraction of the data-centre figure .

Netflix rejected a "forklift" move. It rebuilt a monolithic application as hundreds of microservices and denormalized its data onto NoSQL databases . All customer-facing services were in the cloud before 2015, billing moved last, and in early January 2016 Netflix shut down the last data-centre infrastructure its streaming service used .

Netflix's own posts disagree on the dates. A 2023 post says streaming ran "fully" on AWS by 2010; a 2018 post says the move began in 2007. This study follows the dedicated 2016 account: 2008 to January 2016 .

The classic stack, and what happened to it

Technology — Original problem — Documented role — Current public status; Eureka — Finding instances in a dynamic cloud without a central load balancer — Discovery, load balancing and failover for mid-tier servers — 2.0 discontinued; 1.x "still an active project" and core to Netflix discovery; Zuul — One front door for 1,000+ device types — Edge routing, failover, load shedding — README describes an active L7 gateway; Hystrix — Cascading latency between dependencies — Isolation, circuit breakers, fallbacks — Maintenance mode since 2018; final release 1.5.18; Ribbon — Client-side IPC and load balancing — Load balancing over Eureka's registry — Maintenance since 2016, but core modules "deployed at scale in production"; Spinnaker — Deploying across growing numbers of regions — Multi-cloud continuous delivery — Powers "the vast majority" of Netflix deployments (Dec 2025); Titus — Running containers in a VM-based cloud — Container management on EC2 — Open-source repos archived 2022 ; still the internal platform in 2026

Eureka: service discovery

Problem. In a cloud where instances come and go, callers need to find healthy instances without a central load balancer that becomes a single point of failure. Netflix built Eureka and Ribbon early and chose client-side load balancing; the 2012 Christmas Eve outage "solidified this decision" . How it works, conceptually. Instances register with Eureka; clients fetch the registry and pick an instance themselves. If Eureka is down, clients keep running on their last copy of the data . Limitations. Eureka itself became a single point of failure, which is why clients tolerate stale data . Today. Eureka 2.0 was discontinued; 1.x remains "a core part of Netflix's service discovery system" . In 2023 its registrations fed Netflix's new Envoy service-mesh control plane .

Zuul: the edge

Problem. Many device types, constant change and a need for insight and resilience at the front door . History. Zuul launched in June 2013 with dynamically compiled Groovy filters, in front of an API handling more than 50,000 requests per second at peak . Zuul 2 moved to asynchronous, non-blocking Netty in 2016, mainly to hold persistent connections to devices; Netflix candidly said its performance hopes "have differed from the results" . By 2018 Zuul 2 was the front door for all cloud traffic: 80+ clusters and over 1 million requests per second . Resilience features. Adaptive retries, origin concurrency protection, warm-up of cold instances (an "order of magnitude improvement in availability") and choice-of-two load balancing . Today. The README describes an active L7 gateway . No newer scale figures are published.

Hystrix: isolating failure

Problem. Distributed calls fail and slow down; without isolation one slow dependency can exhaust a caller's threads. Role. Thread or semaphore isolation, circuit breakers and fallbacks, executing tens of billions of thread-isolated calls a day in 2012 . Today. Maintenance mode since November 2018. Netflix favours adaptive approaches such as adaptive concurrency limits and recommends resilience4j for new projects .

Ribbon: client-side load balancing

Role. Client-side IPC and load balancing, internally called "NIWS" . Today. In maintenance since April 2016, but the README says ribbon-core, ribbon-eureka and ribbon-loadbalancer are "deployed at scale in production" . In 2023 Netflix began moving IPC features into an Envoy-based mesh and called itself "still early in our service mesh journey" .

Spinnaker: deployment

History. Open-sourced in November 2015 after more than a year in production; it replaced Asgard and was built with Google, Microsoft and Pivotal . Today. It "powers the vast majority of Netflix's software deployments". Netflix adopted Temporal underneath it in 2021, cutting transient deployment failures from 4% to 0.0001% .

Titus: containers

Titus launched up to three million containers a week in April 2018 across tens of thousands of EC2 VMs, built on Apache Mesos . Its open-source repositories were archived in 2022 , yet a June 2026 Netflix post describes Titus running workloads across cells that are Kubernetes clusters, with Kueue replacing most custom batch queuing . How a Kubernetes cluster itself schedules, starts and replaces containers is explained, with simulations, in the Kubernetes deep dive.

An AWS page says Netflix "migrated to Amazon EKS within months" but does not say what moved, and no Netflix post found confirms it. This study does not say Titus was replaced .

Other concerns

• Configuration. Archaius combines static and dynamic configuration .
• Frameworks. Netflix moved to Spring Boot from 2018 and standardized on it by 2021 .
• APIs. In 2012 the one-size-fits-all REST API gave way to per-device endpoints written by UI teams . For its studio systems, Netflix replaced a GraphQL monolith with a federated graph in 2020 and open-sourced its DGS framework in 2021 .
• Workflows. Conductor orchestrated long-running content workflows from 2016; Netflix stopped maintaining the open-source project in December 2023 .
• Complexity. By 2023 internal IPC mixed REST, GraphQL and gRPC across Java, Node.js and Python .

Editorial: modern equivalents of these patterns include service meshes (Envoy, Istio), Kubernetes service discovery, resilience libraries such as resilience4j, and GitOps-style delivery. Netflix itself names Envoy, resilience4j and Kubernetes; the others are general alternatives, not Netflix choices.

7. Data Architecture

Netflix separates online stores that services read and write while a member waits from analytical systems that process events and history in bulk. The diagram follows Netflix's published event pipelines; it is not a map of all of Netflix's private data infrastructure.

Storage by documented workload

Technology — Documented workload — Period; Apache Cassandra — "Backbone" for sign-ups, viewing history, real-time analytics and live streaming — 2024; EVCache — Memcached-based cache in front of many read paths; above 30M requests/s at peak — 2016; current README; Key-Value abstraction — One API over Cassandra, EVCache, DynamoDB and RocksDB — 2024; TimeSeries abstraction — Cassandra for durable data, Elasticsearch for indexing; designed for up to 10M writes/s — 2024; MySQL — Structured relational data for recommendations — 2013; Amazon S3 — The data warehouse, with compute separated — 2014; Apache Iceberg — Warehouse table format; created at Netflix — 2017–2023; Elasticsearch — Real-time sink: ~150 clusters, ~1.3 PB — 2016; Apache Druid — Real-time device and playback metrics — 2020

Moving data

Before 2016 events went from Chukwa into S3 and then into Hive, with up to ten minutes of latency . Keystone, fronted by Kafka, went live in December 2015 and carried about 500 billion events and 1.3 PB a day in February 2016 . By 2018 it ran Flink stream processing as a service at "trillions of events" a day . Data Mesh (2022) generalized it into a platform for moving and processing data between Netflix systems, starting from change data capture .

Consistency and replication trade-offs

EVCache is explicitly a best-effort cache that favours speed over consistency . Across three regions it replicates by sending metadata through Kafka, with replication under one second at the 99th percentile for most caches (2016) . In the 2013 Active-Active design, Cassandra handled cross-region replication: a million records written in one region were all readable in the other 500 ms later .

Early benchmarks matter for context, not as current figures: in 2011 a 288-instance Cassandra cluster sustained 1.1 million client writes per second and scaled linearly .

Why these technologies, according to Netflix

• Cassandra and EVCache for write-heavy, key-value access. Netflix's 2013 personalization post says EVCache is a better fit for intensive, constant writes, while MySQL suits structured data but has scalability limits when distributed .
• Abstraction layers. The 2024 Key-Value layer hides the store behind one API and lets a namespace combine Cassandra with an EVCache cache .
• Kafka in front. Keystone puts Kafka between producers and the router so producers never wait on downstream systems .
• One Flink cluster per job. Keystone isolates jobs completely, with shared ZooKeeper and S3 for checkpoints, jobs on Titus and deployment through Spinnaker .
• Iceberg. It was designed to improve on the Hive table layout, began at Netflix and graduated as an Apache project in 2020 .

Batch processing and the warehouse

In 2014 the warehouse held 10 PB on S3, with ETL in Pig and Hive and interactive Presto queries . By 2023 batch datasets lived in Iceberg tables processed by Maestro workflows running Spark SQL; an incremental redesign of one pipeline used about 10% of the original resources . In 2024 Maestro ran about half a million jobs a day , and Metaflow, originally built at Netflix, supports over 3,000 AI and ML projects there .

Stream processing

Keystone serves analytics; Mantis is Netflix's separate platform for operational stream processing . Druid ingests real-time playback quality metrics from Kafka at over 2 million events per second (2020) .

Editorial: common alternatives include Apache Pulsar or Amazon Kinesis for event transport, Spark Structured Streaming for stream processing, Delta Lake or Apache Hudi as table formats, and ScyllaDB or Amazon DynamoDB for wide-column storage. Netflix has not said it evaluated these.

Netflix has published no Keystone or Data Mesh volumes after 2018, and no current warehouse size on a Netflix-owned page this research could verify.

8. Recommendation and Personalization Systems

This chapter separates general recommendation-system principles, labelled as such, from documented Netflix implementations, which are cited.

General principle: a streaming catalogue is too large to browse, so a recommender's job is to put a few likely choices in front of each person quickly. Netflix cites consumer research that a member loses interest after perhaps 60 to 90 seconds of choosing, having looked at 10 to 20 titles .

What Netflix says it is worth

• 75% of what people watched came from some form of recommendation in 2012 .
• The recommender influenced about 80% of hours streamed in 2015 .
• Netflix estimated personalization and recommendations save it more than $1B a year by reducing churn .

The home page

Each row represents three layers of personalization: which genre or theme, which titles within it, and their order . A typical home page had about 40 rows with up to 75 titles each . Pages are built per profile and per device: candidate rows are filtered, ranked, selected for relevance and diversity, de-duplicated and formatted . A learned page-generation algorithm replaced a rule-based template around 2014 .

Batch versus online computation

Netflix's 2013 architecture post splits the work three ways :

• Offline. Batch jobs with relaxed timing that may go stale, such as training and precomputing lists on Hadoop with Hive or Pig, published through an internal tool called Hermes .
• Nearline. Computed in response to events and stored asynchronously, for example updating recommendations the moment a member starts watching, through a framework called Manhattan .
• Online. Real time, bound by latency SLAs, so it needs a fast fallback such as a precomputed result .

In practice they combine: most recommendations are computed offline and freshened online with real-time signals . Inputs fall into models (trained offline), data (stored) and signals (fresh context such as recent plays, device and time) . Results were stored in Cassandra, EVCache and MySQL .

Newer Netflix posts do not use the offline/nearline/online terms. Whether a "nearline" tier still exists under any name is not documented.

Ranking and candidate selection

Two Netflix Prize algorithms, matrix factorization (SVD) and RBMs, went into production; the Grand Prize ensemble did not, because its gains did not justify the engineering effort . Ranking became learning-to-rank over many features, trained on billions of ratings, millions of daily plays with context and impression data . Named algorithms include the Personalized Video Ranker, Top-N, Trending Now, Continue Watching and "Because You Watched" .

Artwork and evidence

Evidence-selection algorithms choose what supports a recommendation, including which image to show . Since 2017 artwork is chosen per member with contextual bandits , using context such as viewing history, country, language, device and time , at a peak of over 20 million requests per second .

From many models to one

By 2025 Netflix ran many independently trained models, which had become costly to maintain, and was building a foundation model to centralize member-preference learning . It is trained GPT-style on tokenized interactions from over 300 million users . Embeddings are computed in batch and used both offline and online , and Netflix reports a scaling law for the model . It also frames recommendation as a contextual bandit with a proxy reward that tracks long-term satisfaction rather than clicks .

Experimentation

Every product change goes through A/B testing before becoming the default . Members are assigned to "cells", the default cell is the control, and the main metrics are streaming hours and retention . Assignment is batch or real-time and stratified by country and device; in 2016 allocations lived in Cassandra behind EVCache, with events flowing through Kafka to Hive for analysis at 150K–450K requests per second .

Algorithm tests usually run two to six months, and detecting a 0.1% change in retention needs about two million members per cell . To move faster, Netflix uses interleaving as a first stage for ranking changes: it needed more than 100 times fewer users than its most sensitive A/B metric, and its results agreed strongly with later A/B tests .

Evaluation

Page layouts are evaluated offline with two-dimensional recall metrics and models of how members scan the page . Artwork models are evaluated offline with "replay" on randomized exploration data before an A/B test .

9. Reliability and Fault Tolerance

At Netflix's scale, partial failure is normal. The goal is to keep a failure partial: a slow service should degrade one feature, not the whole product, and a broken region should move members elsewhere rather than stop them watching.

The building blocks

• Timeouts, circuit breakers and fallbacks. Hystrix (2012) wrapped dependency calls with isolation, circuit breakers and fallbacks . It is now in maintenance mode; Netflix prefers adaptive approaches .
• Bulkheads. Hystrix's thread and semaphore isolation is a form of what is often called the bulkhead pattern (editorial term).
• Adaptive concurrency limits. Rather than hand-tuned limits that go stale, services discover their limit the way TCP finds a congestion window . By 2023 this was ported to Envoy .
• Graceful degradation under load. Zuul gives each request a priority and sheds the least important first, while telling devices how to back off .
• Regional resilience. Services are designed so any region can serve a member, and traffic is evacuated from an unhealthy region .
• Chaos engineering. Netflix deliberately injects failures in production to prove these mechanisms work .

Retries and retry storms

Retries help with transient errors but multiply load when a service is already struggling. Netflix's ChAP experiments found mistuned retry policies, CPU-intensive fallbacks and unexpected interactions between circuit breakers and load balancers . Zuul 2 added adaptive retries and origin concurrency protection , and prioritized load shedding sends retry hints (maxRetries, retryAfterSeconds) back to clients .

Prioritized load shedding

Before 2020 Netflix "had on/off circuit breakers, but no progressive way to shed load". Zuul now scores each request from 1 to 100 within NON_CRITICAL, DEGRADED_EXPERIENCE or CRITICAL and sheds progressively. The taxonomy is validated with FIT and ChAP, and in a 2020 incident similar to a 2019 outage, playback was not affected .

Regions as fault domains

When — Change; Dec 2013 — Active-Active across US-East-1 and US-West-2: stateless services, in-region resources only, no cross-region calls on the user path, asynchronous replication; 2014–2016 — Global Cloud removes EU-West-1 as a single point of failure; any member can be served from any of three regions; 2018 — Project Nimble cuts regional failover from about 50 minutes to 8, using pre-provisioned "dark capacity"; 2019 — Evacuation scaling uses per-service demand, in an N+1 architecture with regions as fault domains

Chaos engineering

• 2011: Chaos Monkey. It randomly disables production instances, run during business hours with engineers watching . The same year Netflix described a whole "Simian Army", noting much of it was still an aspiration .
• 2013: whole-region tests. Chaos Gorilla, split-brain and Chaos Kong exercises validated Active-Active; traffic was held in one region for over 24 hours .
• 2014: FIT. Failure injection narrowed to tagged requests: a test account first, then a percentage, then everyone .
• 2015: Chaos Kong pays off. Regular Kong exercises left Netflix with only a "brief availability blip" during a DynamoDB incident in US-EAST-1 . The same year Netflix named the discipline and published its principles .
• 2016: Chaos Monkey 2.0. A rewrite integrated with Spinnaker, terminating VMs and containers only .
• 2017: ChAP. Experiment and control clusters, with automatic stop on an error budget .
• 2021: Simian Army archived. The repository was archived .

How Netflix runs Chaos Monkey internally today is not described in any post after 2016. Netflix has not published recovery-time objectives, and this study does not invent them.

Observability as part of reliability

Evacuations depend on demand data from Atlas and tracing , and ChAP compares experiment and control groups using Mantis streams . See the observability chapter.

10. Networking and Performance

Streaming quality is decided as much by the network as by the services. This diagram keeps three concerns apart: decisions made by Netflix software, the transport and servers they run on, and the internet paths beneath.

The terms, briefly (general principles)

• Latency is how long a round trip takes; bandwidth is the capacity of a link; throughput is what a session actually gets.
• Congestion happens when many flows compete for a link, causing queuing delay and loss.
• Adaptive bitrate lets a player trade picture quality for continuity as throughput changes.

What Netflix does about them

• Shorten the path. Open Connect's mission is to localize traffic close to members , and steering prefers the most specific, shortest network route to the client .
• Cache ahead of demand. On-demand assets are pre-positioned rather than fetched on a miss .
• Use fewer bits. Better encodes deliver more viewing per gigabyte; hours streamed per GB rose by more than 200% over five years .
• Send at the right rate. With app-informed pacing, the bitrate algorithm tells TCP how fast it needs to send. In large-scale experiments this reduced instantaneous throughput by 62%, retransmissions by 50% and round-trip time by 19%, while improving quality of experience .
• Measure the experience. Netflix tracks start-up wait, rebuffers, overall quality and quality switches .

Netflix-specific decisions versus general practice

Concern — General streaming practice (editorial) — Netflix's documented decision; Server selection — DNS or anycast to a CDN point of presence — URLs ranked by a control plane using BGP data; Cloud region selection — Geo-DNS — Latency-based DNS from real-user probes; Caching — Fill on demand — Push fill off-peak; Transport — Send as fast as possible — App-informed pacing, rolling out in 2025; Encryption — TLS in user space — TLS in the kernel sendfile path, later on the network card

Transport: TCP and TLS

Netflix contributed asynchronous sendfile, kernel TLS, the RACK and BBR TCP stacks and TCP pacing to FreeBSD . In 2017 an appliance served 100% TLS traffic at 90 Gbps on the default FreeBSD TCP stack; RACK and BBR could not yet reach 100 Gbps . The 2021 slides pin "RACK / BBR TCP pacers" to CPU domains, which suggests they ran on the high-end platform, but not which algorithm is the default .

Video transport encryption began around 2015–2016 with AES-GCM and in-kernel encryption . Consumer-electronics devices moved to TLS 1.3 in 2020, using 0-RTT resumption to reduce play delay .

No Netflix-owned source found says whether QUIC or HTTP/3 is used for video , which congestion-control algorithm is the current default , or whether all video is now served over HTTPS .

Start-up time and rebuffering

Netflix has published improvements rather than current baselines:

• Optimized 4K encodes cut rebuffers by over 65% and initial play delay by about 10% .
• Optimized HDR encodes cut rebuffers by 40% .
• AV1 on TVs cut play delay by about 2% .
• AV1 sessions had 45% fewer buffering interruptions .
• Predictive caching on the device cut start-up wait .

Quality-of-experience testing (rebuffer rate, play delay, time to quality) was a gate for putting network-card TLS offload into production .

Measuring the network

FAST.com tests a member's speed against production appliances chosen by the same steering control plane, over HTTPS only . Netflix streams telemetry from its own network devices using OpenConfig and gNMI .

11. Security Architecture

Netflix names three mechanisms working together: adaptive bitrate for quality, DRM "to protect our service" and TLS "to protect customer privacy" . Below them sit device authentication, edge authentication and identity for every internal service.

Concern — What Netflix has documented — Evidence; Account authentication — Tokens are checked and renewed at the edge; services receive a short-lived signed "Passport" — Historical (2021); Device-to-server messaging — Message Security Layer (MSL): integrity, encryption, authentication, replay protection — Historical (2014); Playback entitlement — Playback services check authorization and licensing before choosing files — Confirmed; Content protection — Streams always protected by pre-encoded DRM , packaged with Common Encryption — Historical; Licensing — Short-lived, single-use licenses; one service per DRM technology — Historical (2017); Transport encryption — HTTPS for video from about 2015–2016; TLS 1.3 on TV devices from 2020 — Historical; Service identity — Metatron private PKI: short-lived certificates and mutual TLS for every workload — Confirmed (2026); Secure distribution — Appliances hold no member data and only report status and serve content — Confirmed

Netflix-owned sources found do not name PlayReady or FairPlay . The license protocol, key hierarchy, per-device DRM security levels and the link between DRM level and resolution are not documented .

Authentication at the edge

Netflix moved authentication into Zuul filters. They inspect, decrypt and renew tokens such as MSL tokens and cookies; MSL is terminated at the edge, so external tokens never travel deeper . Inside, identity travels as a "Passport": a per-request protobuf with user and device identity, integrity-protected with HMAC-SHA-256 and carrying an authentication level from LOW to HIGHEST . The scale behind the change was over 2.5 million requests per second, many needing authentication .

Device security with MSL

In 2014 Netflix replaced HTTPS plus a homegrown mechanism ("NTBA") with the Message Security Layer, which needs no clock synchronisation and has pluggable device and user authentication . MSL is open source, its documentation was reviewed by an external security firm, and its wiki describes Widevine integration .

DRM and licensing

• Android downloads. Widevine was chosen for offline licenses and hardware decryption with a software fallback. Device fragmentation was a problem: some devices lacked the needed level or had insecure implementations .
• Web. Encrypted Media Extensions use Common Encryption with AES-128 counter mode, and WebCrypto protects JavaScript-to-server traffic .
• Packaging. The packager integrates with Netflix's security backend for key generation, segment encryption and packager authentication; Live reuses the same components .
• Download licenses. Downloads are checked against business rules such as studio limits, can be renewed, and are released when the content is deleted .

Encrypting video in transit

Netflix began encrypting video transport with HTTPS around 2015–2016 to protect viewing privacy. It preferred AES-GCM, moved bulk encryption into the kernel's sendfile path and chose Intel's ISA-L library, gaining up to 30% . A 100 GbE appliance went from about 58 Gbps of TLS traffic to about 90 Gbps after optimisation . TV devices moved to TLS 1.3, always with forward-secret key exchange .

Service identity

Internal service-to-service authentication runs on Metatron, a private PKI. Every workload gets a short-lived X.509 certificate after attestation in its environment, and services authenticate each other with mutual TLS . Certificates are provisioned to each EC2 instance at boot .

Other documented controls

• Studio web apps reach the internet through Wall-E, a Zuul-based gateway with SSO, WAF, DDoS prevention and logging, following the "Zero Trust" idea .
• BLESS, an SSH certificate authority on AWS Lambda, is being archived .
• Appliances are single-tenant, separate serving from management, and Netflix uses RPKI-based route filtering .

General principle: authenticate once at the boundary, then propagate a verifiable identity internally. That is what the Passport design does, but how Netflix authorizes individual internal calls is not documented.

12. Observability

Observability is hard here for two reasons. On the cloud side, one request touches many services across regions and more than 1,000 device types . On the delivery side, the bytes come from appliances spread across thousands of partner sites, which report back to the control plane .

What Netflix built

• Metrics: Atlas. Netflix's dimensional time-series system for near-real-time operational insight, keeping recent data in memory . It replaced a homegrown system that struggled at about 2 million series and sustained over 1.2 billion series during failover exercises in 2014 .
• Stream processing for operations: Mantis. It cut detection time from tens of minutes to seconds and charges for events only when someone is subscribed .
• Tracing. Request tracing inspired by Dapper, published to Kafka . Edgar builds troubleshooting views on top and captures 100% of "interesting" traces rather than a fixed sample .
• Application health: Telltale. It combines metrics, streams, deployments, canaries and quality of experience into one health model for over 100 production applications .

This study does not assume Netflix uses any monitoring product in the Bit Culled catalogue. Only tools Netflix itself names are listed.

Logging versus streaming

By 2018, storing all raw application logs no longer scaled, so Netflix moved to streaming with filters in Mantis . Mantis also drives control loops: the ChAP comparison between experiment and control, and Zuul's real-time anomaly detection on origins .

Infrastructure monitoring

• Appliances. OCAs report health and load, which feed directly into content routing .
• Network devices. Netflix streams their telemetry using OpenConfig and gNMI and open-sourced gnmi-gateway .

Playback quality monitoring

Druid stores real-time device and playback quality metrics: over 2 million events per second and 115 billion rows a day in 2020 . For Live events, Netflix processed up to 38 million events per second using Atlas, Mantis, Lumen, Kafka and Druid .

Current status

The Atlas documentation still describes it in the present tense , and its repository carries a 2014–2026 copyright . Mantis's repository describes the platform with no status notice . Neither publishes current volumes.

13. Architectural Evolution

Every event below has a source and a date or bounded period. Use the era selector to focus on one version of the architecture. Historical entries describe what was true then, not necessarily now.

How to read the eras

• Data centre and migration (2007–2016). A monolith in Netflix's own data centres, rebuilt in AWS as microservices after the 2008 outage . Open Connect replaced third-party CDNs from 2011 .
• Active-Active (2013–2016). Two US regions serving at once, then a "global cloud" of three .
• Global cloud (2016–2020). Spinnaker, Titus, Zuul 2, Keystone, per-title and shot-based encoding .
• Current (2021–2026). Cosmos media services, an Envoy mesh fed by Eureka, Temporal under Spinnaker, Titus on Kubernetes cells, AV1 at scale and a recommendation foundation model .

Where the sources disagree

• Migration dates. 2008 to January 2016 in the dedicated 2016 account; other posts say 2007 or 2010 .
• Regions. Three regions (2016 and 2023 statements), five on the backbone (2025) and four on an AWS page .
• Catalogue per appliance. "Nearly all" per deployment (2021) against "a portion" per appliance (2025) .

14. Why These Technologies and Decisions?

Editorial analysis. Problems, selected solutions and Netflix's stated reasons are cited. "Alternatives" and "Lessons" are Bit Culled's analysis unless a citation says Netflix named them.

Decision — Problem — Selected — Why suitable — Trade-offs — Alternatives; CDN placement — Video was a large share of ISP traffic; demand-driven caching wastes upstream capacity — Own CDN with appliances inside ISPs and at IXPs — Netflix can predict demand and fill off-peak — Netflix funds hardware and operations ; appliances depend on AWS — Third-party CDNs, which Netflix used first; Microservices — A vertically scaled monolith was a single point of failure — Hundreds of microservices on AWS — Independent scaling and deployment — IPC complexity across many protocols and languages — A modular monolith (editorial); Distributed storage — Write-heavy, high-availability data — Cassandra behind a Key-Value abstraction — Horizontal scale, multi-region replication — Eventual consistency (editorial) — DynamoDB, ScyllaDB (editorial; DynamoDB is a documented backend ); Caching — Read-heavy personalized data — EVCache, best effort, speed over consistency — Very high request rates — Possibly stale reads — Redis (editorial); Event processing — Batch-only pipeline with up to 10 minutes' latency — Kafka-fronted Keystone, then Flink — Producers decoupled from consumers — Operating thousands of jobs — Kinesis, Pulsar (editorial); Resilience — Cascading failures and fixed limits that go stale — Hystrix, then adaptive limits and prioritized shedding — Limits adapt to load — Tuning and validation effort — resilience4j, named by Netflix; Service discovery — Dynamic instances without a central load balancer — Eureka with client-side load balancing — Clients survive registry outages on stale data — Registry as a dependency — Envoy mesh, adopted by Netflix; Video encoding — One ladder over- or under-served titles — Per-title, then shot-based optimization — Same quality, fewer bits — Much more compute per title — Fixed ladders (Netflix's own starting point ); Personalization — Too much choice; members give up within 60–90 s — Offline, nearline and online computation — Freshness without an expensive request path — Many specialized models to maintain — A centralized foundation model, which Netflix is building

Lessons per decision (editorial)

• CDN placement. Owning delivery paid off because Netflix knew what members would watch and when. Without that predictability, a commercial CDN's demand-driven fill is the safer default.
• Microservices. The migration was a rebuild, not a lift-and-shift ; the benefit came from redesigning around failure, not from the word "microservices".
• Storage. Hiding stores behind an abstraction let Netflix change backends without changing callers .
• Caching. Be explicit about which data may be stale; EVCache's guarantee is "best effort" by design .
• Events. Put a durable log between producers and consumers so neither waits on the other .
• Resilience. Prefer mechanisms that adapt over limits someone has to tune, and test them with controlled experiments .
• Discovery. Plan for the discovery system itself failing .
• Encoding. Measure perceived quality (VMAF) rather than bitrate, then optimise for it .
• Personalization. Precompute what you can, add real-time signals on top, and always keep a fallback .

Technology deep dives

Each panel lists Netflix's documented use, its status and sources. Where a matching profile exists in the Bit Culled catalogue, it links there.

15. Lessons for Engineering Teams

Editorial. Netflix built these systems for a problem few companies share: very large-scale video delivery to hundreds of millions of members. Copy the principles, not the stack.

Small applications

• Separate deciding from serving. Even a small product benefits from serving static, heavy content (video, images, downloads) from a CDN or object store rather than from application servers, the same split Netflix draws between its control plane and Open Connect .
• Precompute what is slow. Netflix computes most recommendations offline and freshens them online . A nightly job and a cache will take most products a long way.
• Have a fallback. An online feature should degrade to a precomputed or default answer .
• Use a managed database and a cache before considering anything distributed.

Growing SaaS products

• Invest in deployment. Netflix's deployment tooling now powers "the vast majority" of its deployments ; automated, repeatable delivery matters long before microservices do.
• Make overload a designed state. Decide which requests matter most and shed the rest, as Zuul does .
• Measure before you optimise. Netflix tracks start-up time, rebuffers and quality ; pick the few metrics your users feel.
• Run controlled experiments for product changes, with a control group .
• Put a log between producers and consumers once several systems need the same events .

Large distributed platforms

• Treat regions as fault domains and practise evacuating them .
• Inject failure deliberately, starting small and expanding the blast radius .
• Prefer adaptive limits to hand-tuned ones .
• Give every workload an identity and authenticate service-to-service traffic .
• Own the hard part of your domain. For Netflix that was delivery and encoding, where its knowledge of demand gave it an advantage .

When not to adopt complicated infrastructure

• No measured problem. If you cannot name the failure or bottleneck a component solves, you are adding operational cost without benefit.
• Too few people. Hundreds of services need people to own them. Netflix's own posts show the cost: maintenance-mode libraries , a service mesh it called "still early" and thousands of stream-processing jobs .
• Unpredictable demand. A pre-positioned CDN like Open Connect works because demand is predictable . Most products should rent delivery.
• Old blog posts as blueprints. Several famous Netflix tools are archived or in maintenance mode, and Netflix has moved on to adaptive, mesh-based and Kubernetes-based approaches .

Principles versus stacks

Learning from Netflix means asking why it made each choice and whether your constraints match. Is your demand predictable? Is a single failure as costly? Can you staff the platform? Copying the stack means adopting Eureka, Zuul or a custom CDN because Netflix did. The first transfers; the second usually does not.

Technologies

• Open Connect Appliance: Netflix’s own cache appliances, embedded in ISPs and at internet exchanges, serving all on-demand video.
• NGINX: Web server on every Open Connect Appliance, serving audio and video files over HTTP/HTTPS; extended for Live proxy caching.
• FreeBSD: Operating system of Open Connect Appliances, tracking FreeBSD-CURRENT. Netflix contributed kernel TLS, asynchronous sendfile and the RACK and BBR TCP stacks.
• BIRD: Routing daemon on each appliance that collects ISP routes over BGP and shares them with the steering system in AWS.
• Amazon S3: Holds packaged titles for Open Connect fill, lands pipeline events and stores the data warehouse.
• Apache Cassandra: The “backbone” for sign-ups, viewing history, real-time analytics and live streaming; durable store behind the Key-Value and TimeSeries abstractions.
• EVCache: Memcached-based distributed cache in front of many read paths, replicated across regions.
• Apache Kafka: Fronts the Keystone event pipeline; transport for Data Mesh; source for Druid; used in tracing and experimentation pipelines.
• Apache Flink: Stream processing for Keystone (one cluster per job, 2018) and Data Mesh processors (2022).
• Apache Spark: Spark SQL jobs over Iceberg tables in Maestro workflows; a Keystone consumer; Spark Streaming in the 2016 experimentation platform.
• Apache Iceberg: Table format of the warehouse; a Data Mesh sink.
• Elasticsearch: Real-time sink of the event pipeline (~1.3 PB in 2016), index store of the TimeSeries abstraction, near-real-time A/B views.
• Apache Druid: Real-time device and playback quality metrics; used for Live event monitoring.
• Eureka: Service registry for discovery, load balancing and failover of mid-tier servers; source of truth for the Envoy mesh control plane.
• Zuul: Edge gateway for all cloud traffic: routing, regional failover, prioritized load shedding, edge authentication and failure injection.
• Hystrix: Latency and fault-tolerance library: isolation, circuit breakers and fallbacks for dependency calls.
• Ribbon: Client-side IPC and load balancing over Eureka.
• Envoy: Service mesh taking over IPC features from 2023, with discovery data from Eureka and adaptive concurrency limiting ported in.
• Spinnaker: Continuous delivery for most Netflix deployments; integrates with Titus and Chaos Monkey.
• Titus: Netflix’s container platform, from the netflix.com API to ML training and video encoders.
• Kubernetes: Titus cells are Kubernetes clusters; Kueue handles most batch queuing (2026).
• Atlas: Primary dimensional, in-memory time-series telemetry; feeds health models and evacuation planning.
• Mantis: Stream processing for operational insight: ChAP comparisons, Zuul anomaly detection, filtered log streams.
• VMAF: Perceptual video quality metric used by the quality service and the shot-based encoding optimizer.
• Temporal: Durable execution beneath Spinnaker’s cloud operations since 2021.
• Maestro: Data and ML workflow orchestrator: about half a million jobs a day; also runs A/B test pipelines.
• Metaflow: Originally developed at Netflix; supports over 3,000 AI and ML projects there.
• MySQL: Structured relational data in the 2013 personalization stack; a Data Mesh change-data-capture source in 2022.
• PostgreSQL: A Data Mesh change-data-capture source (via DBLog).
• CockroachDB: A Data Mesh change-data-capture source.
• RocksDB: One of the backends the Key-Value abstraction works with; no specific workload named.
• Message Security Layer: Device-to-server message security (integrity, encryption, authentication, non-replay), terminated at the edge.

Sources

1. Completing the Netflix Cloud Migration — Netflix (about.netflix.com). Authors: Yury Izrailevsky, Stevan Vlaovic, Ruslan Meshenberg, 2016-02-12 (as shown on the page)
2. The Netflix Simian Army — Netflix TechBlog (Yury Izrailevsky, Ariel Tseitlin), 2011-07-19
3. Active-Active for Multi-Regional Resiliency — Netflix TechBlog (Ruslan Meshenberg, Naresh Gopalani, Luke Kosewski), 2013-12-02 per the footer "Originally published at techblog.netflix.com on December 2, 2013". The Medium header shows "Feb 12, 2013", which can't be right because the post mentions Zuul being open-sourced in June 2013
4. Global Cloud — Active-Active and Beyond — Netflix TechBlog (Peter Stout), 2016-03-30
5. Project Nimble: Region Evacuation Reimagined — Netflix TechBlog (Luke Kosewski, Amjith Ramanujam, Niosha Behnam, Aaron Blohowiak, Katharina Probst), 2018-03-12
6. Evolving Regional Evacuation — Netflix TechBlog (Niosha Behnam), 2019-09-23
7. FIT : Failure Injection Testing — The Netflix Tech Blog (Kolton Andrus, Naresh Gopalani, Ben Schmaus), 2014-10-23
8. ChAP: Chaos Automation Platform — Netflix TechBlog (Ali Basiri, Aaron Blohowiak, Lorin Hochstein, Nora Jones, Casey Rosenthal, Haley Tucker), 2017-07-26
9. Keeping Netflix Reliable Using Prioritized Load Shedding — Netflix TechBlog (Manuel Correa, Arthur Gonigberg, Daniel West), 2020-11-02
10. Telltale: Netflix Application Monitoring Simplified — Netflix TechBlog (Andrei Ushakov et al.), 2020-08-14
11. Netflix Chaos Monkey Upgraded — Netflix TechBlog (Lorin Hochstein, Casey Rosenthal), 2016-10-19
12. Chaos Engineering Upgraded — Netflix TechBlog (Ali Basiri, Lorin Hochstein, Abhijit Thosar, Casey Rosenthal), 2015-09-25
13. Open Sourcing Zuul 2 — Netflix TechBlog (Arthur Gonigberg, Mikey Cohen, Michael Smith, Gaya Varadarajan, Sudheer Vinukonda, Susheel Aroskar), 2018-05-21
14. Zuul 2 : The Netflix Journey to Asynchronous, Non-Blocking Systems — Netflix TechBlog, 2016-09-21
15. Announcing Zuul: Edge Service in the Cloud — The Netflix Tech Blog, 2013-06-12
16. Global Continuous Delivery with Spinnaker — The Netflix Tech Blog, 2015-11-16
17. Titus, the Netflix container management platform, is now open source — Netflix TechBlog (Amit Joshi, Andrew Leung, et al.), 2018-04-18
18. Updates on Netflix's Container Management Platform — Netflix TechBlog, 2017-11-14
19. How Netflix Scales its API with GraphQL Federation (Part 1) — Netflix TechBlog (Tejas Shikhare), 2020-11-09
20. How Netflix Scales its API with GraphQL Federation (Part 2). Page title reads "Scaling Netflix's API via GraphQL Federation (#2) — Netflix TechBlog (Tejas Shikhare), 2020-12-11
21. Embracing the Differences : Inside the Netflix API Redesign — The Netflix Tech Blog (Daniel Jacobson), 2012-07-09
22. Optimizing the Netflix API — The Netflix Tech Blog (Ben Christensen), 2013-01-15
23. Introducing Atlas: Netflix's Primary Telemetry Platform — The Netflix Tech Blog (Brian Harrington, Roy Rapoport), 2014-12-12
24. Introducing Hystrix for Resilience Engineering — The Netflix Tech Blog (Ben Christensen), 2012-11-26
25. Open Sourcing Mantis: A Platform For Building Cost-Effective, Realtime, Operations-Focused Applications — Netflix TechBlog (Cody Rioux et al.), 2019-10-21
26. Edgar: Solving Mysteries Faster with Observability — Netflix TechBlog (Elizabeth Carretto), 2020-09-02
27. Lessons from Building Observability Tools at Netflix — Netflix TechBlog (Kevin Lew, Sangeeta Narayanan), 2018-06-04
28. Performance Under Load (subtitle: Adaptive Concurrency Limits @ Netflix) — Netflix Technology Blog (Eran Landau, William Thurston, Tim Bozarth), 2018-03-23
29. Netflix Conductor: A microservices orchestrator — Netflix TechBlog, 2016-12-12
30. Netflix OSS and Spring Boot — Coming Full Circle — Netflix TechBlog, 2018-12-18
31. Open Sourcing the Netflix Domain Graph Service Framework: GraphQL for Spring Boot — Netflix TechBlog (Paul Bakker, Kavitha Srinivasan), 2021-02-03
32. Evolving Container Security With Linux User Namespaces — Netflix TechBlog (Fabio Kung et al.), 2020-12-23
33. How Netflix Simplified Batch Compute with Kueue — Netflix TechBlog (Alvin Bao et al.), 2026-06-22
34. How Temporal Powers Reliable Cloud Operations at Netflix — Netflix TechBlog (Jacob Meyers, Rob Zienert), 2025-12-15
35. Zero Configuration Service Mesh with On-Demand Cluster Discovery — Netflix TechBlog (David Vroom, James Mulcahy, Ling Yuan, Rob Gulewich), 2023-08-29
36. Hystrix: Latency and Fault Tolerance for Distributed Systems — Netflix GitHub, README undated
37. commit "Update README.md" (adds "Hystrix Status"), plus commit 1ee6ae235b "deprecated and move hystrix-dashboard to Netflix-skunkworks — Netflix GitHub, 2018-11-19 and 2018-01-10
38. Ribbon — Netflix GitHub, README undated
39. commit "Add maintenance project status to README — Netflix GitHub, 2016-04-18
40. Eureka — Netflix GitHub, undated
41. Eureka wiki (Home) — Netflix GitHub, undated
42. zuul README — Netflix GitHub, undated
43. chaosmonkey README — Netflix GitHub, undated
44. SimianArmy README — Netflix GitHub, archived 2021-03-04
45. atlas README — Netflix GitHub, "Copyright 2014-2026"
46. Atlas Overview — Netflix (atlas-docs), undated
47. titus — Netflix GitHub, archived 2022-07-27
48. Titus Control Plane (ARCHIVED) — Netflix GitHub, archived 2022-05-14
49. conductor README — Netflix GitHub, archived 2023-12-13
50. concurrency-limits README — Netflix GitHub, undated
51. archaius README (2.x branch) — Netflix GitHub, undated
52. dgs-framework README — Netflix GitHub, undated (mentions 2026)
53. mantis README/About — Netflix GitHub, undated
54. Spinnaker home page — Spinnaker project (Linux Foundation footer), undated
55. Projects — Continuous Delivery Foundation, undated
56. Principles of Chaos Engineering — principlesofchaos.org (no organization named on the page), "Last Update: 2019 March"
57. Netflix on AWS: Case Studies, Videos, Innovator Stories — Amazon Web Services, undated (© 2026)
58. System Architectures for Personalization and Recommendation — Netflix TechBlog; Xavier Amatriain, Justin Basilico, 2013-03-27
59. Innovating Faster on Personalization Algorithms at Netflix Using Interleaving — Netflix TechBlog; Joshua Parks, Juliette Aurisset, Michael Ramm, 2017-11-29
60. Decision Making at Netflix — Netflix TechBlog; Martin Tingley with Wenjing Zheng, Simon Ejdemyr, Stephanie Lane, Colin McFarland, 2021-09-07
61. Evolution of the Netflix Data Pipeline — Netflix TechBlog; Real-Time Data Infrastructure Team, 2016-02-15
62. Keystone Real-time Stream Processing Platform — Netflix TechBlog; Zhenzhong Xu on behalf of the Real-time Data Infrastructure and Mantis teams, 2018-09-10
63. Data Mesh — A Data Movement and Processing Platform @ Netflix — Netflix TechBlog; Bo Lei, Guilherme Pires, James Shao, Kasturi Chatterjee, Sujay Jain, Vlad Sydorenko, 2022-08-01
64. Benchmarking Cassandra Scalability on AWS — Over a million writes per second — Netflix TechBlog; Adrian Cockcroft, Denis Sheahan, 2011-11-02
65. Introducing Netflix's Key-Value Data Abstraction Layer — Netflix TechBlog; Vidhya Arvind, Rajasekhar Ummadisetty, Joey Lynch, Vinay Chella, 2024-09-18
66. Introducing Netflix's TimeSeries Data Abstraction Layer — Netflix TechBlog; Rajiv Shringi, Vinay Chella, Kaidan Fullerton, Oleksii Tkachuk, Joey Lynch, 2024-10-08
67. Ephemeral Volatile Caching in the cloud — Netflix TechBlog; Shashi Madappa, 2012-01-27
68. Caching for a Global Netflix — Netflix TechBlog (byline not captured), 2016-03-01
69. Netflix Recommendations: Beyond the 5 stars (Part 1) — Netflix TechBlog; Xavier Amatriain, Justin Basilico, 2012-04-06
70. Netflix/EVCache (README; repo description "A distributed in-memory data store for the cloud") — Netflix (GitHub), undated (repo created 2013-02-08)
71. Using Presto in our Big Data Platform on AWS — Netflix TechBlog; Eva Tse, Zhenxiao Luo, Nezih Yigitbasi, 2014-10-07
72. How Netflix uses Druid for Real-time Insights to Ensure a High-Quality Experience — Netflix TechBlog; Ben Sykes, 2020-03-03
73. Maestro: Netflix's Workflow Orchestrator — Netflix TechBlog; Jun He, Natallia Dzenisenka, Praneeth Yenugutala, Yingyi Zhang, Anjali Norwood, 2024-07-22
74. Incremental Processing using Netflix Maestro and Apache Iceberg — Netflix TechBlog; Jun He, Yingyi Zhang, Pawan Dixit, 2023-11-20
75. Netflix/iceberg (README: "Iceberg has moved!") — Netflix (GitHub), undated (repo created 2017-12-13)
76. IcebergProposal — Apache Software Foundation (Incubator wiki), undated (incubation entered 2018-11-16 per S-DA-27)
77. Iceberg Project Incubation Status — Apache Incubator, 2018–2020 entries
78. Netflix/metaflow (README) — Netflix (GitHub), undated/current (repo created 2019-09-17)
79. Netflix Recommendations: Beyond the 5 stars (Part 2) — Netflix TechBlog; Xavier Amatriain, Justin Basilico, 2012-06-20
80. Learning a Personalized Homepage — Netflix TechBlog; Chris Alvino, Justin Basilico, 2015-04-09
81. Artwork Personalization at Netflix — Netflix TechBlog; Ashok Chandrashekar, Fernando Amat, Justin Basilico, Tony Jebara, 2017-12-07
82. Foundation Model for Personalized Recommendation — Netflix TechBlog; Ko-Jen Hsiao, Yesu Feng, Sudarshan Lamkhede, 2025-03-21
83. Recommending for Long-Term Member Satisfaction at Netflix — Netflix TechBlog; Jiangwei Pan, Gary Tang, Henry Wang, Justin Basilico, 2024-08-29
84. The Netflix Recommender System: Algorithms, Business Value, and Innovation — ACM Trans. Manage. Inf. Syst. 6(4), Art. 13; Carlos A. Gomez-Uribe, Neil Hunt (Netflix, Inc.), Dec 2015
85. It's All A/Bout Testing: The Netflix Experimentation Platform — Netflix TechBlog; Steve Urban, Rangarajan Sreenivasan, Vineet Kannan, 2016-04-29
86. Per-Title Encode Optimization — Netflix Technology Blog, 2015-12-14
87. The Netflix Cosmos Platform — Netflix Technology Blog (Frank San Miguel), 2021-03-01
88. Packaging award-winning shows with award-winning technology — Netflix Technology Blog, 2021-02-26
89. Netflix Cloud Packaging in the Terabyte Era — Netflix Technology Blog, 2021-09-24
90. Bringing AV1 Streaming to Netflix Members' TVs — Netflix Technology Blog, 2021-11-09
91. All of Netflix's HDR video streaming is now dynamically optimized — Netflix Technology Blog, 2023-11-29
92. Rebuilding Netflix Video Processing Pipeline with Microservices — Netflix Technology Blog, 2024-01-10
93. The Making of VES: the Cosmos Microservice for Netflix Video Encoding — Netflix Technology Blog, 2024-04-09
94. HDR10+ Now Streaming on Netflix — Netflix Technology Blog, 2025-03-24
95. AV1 — Now Powering 30% of Netflix Streaming — Netflix Technology Blog, 2025-12-01
96. Netflix/vmaf (README) — Netflix (GitHub), undated; news entries up to 2026-06
97. High Quality Video Encoding at Scale — Netflix Technology Blog, 2015-12-09
98. Behind the Streams: Three Years Of Live at Netflix. Part 1. — Netflix Technology Blog, 2025-07-15
99. Behind the Streams: Building a Reliable Cloud Live Streaming Pipeline for Netflix. Part 2. — Netflix Technology Blog, 2025-09-15
100. Open Connect Overview — Netflix (Open Connect), undated (copyright 2016, 2019, 2026)
101. Driving Content Delivery Efficiency Through Classifying Cache Misses — Netflix Technology Blog, 2025-07-02
102. Engineering Trade-Offs and The Netflix API Re-Architecture — Netflix Technology Blog, 2016-08-23
103. Scaling Event Sourcing for Netflix Downloads, Episode 1 — Netflix Technology Blog (Playback Licensing team), 2017-09-11
104. Netflix Downloads on Android — Netflix Technology Blog, 2017-03-08
105. HTML5 Video at Netflix — Netflix Technology Blog, 2013-04-15
106. Netflix Play API - An Evolutionary Architecture — InfoQ (SECONDARY host; talk by Netflix engineer Suudhan Rangarajan, QCon SF 2018), 2018-12-12
107. Protecting Netflix Viewing Privacy at Scale — Netflix Technology Blog, 2016-08-08
108. Creating Your Own EC2 Spot Market — Netflix Technology Blog, 2015-09-28
109. Serving 100 Gbps from an Open Connect Appliance — Netflix Technology Blog (Drew Gallatin), 2017-09-29
110. How Netflix brings safer and faster streaming experiences to the living room on crowded networks using TLS 1.3 — Netflix Technology Blog (Sekwon Choi), 2020-04-20
111. Message Security Layer: A Modern Take on Securing Communication — Netflix Technology Blog, 2014-10-31
112. Netflix/msl: Message Security Layer — Netflix (GitHub), undated
113. Edge Authentication and Token-Agnostic Identity Propagation (page headline: "Netflix Edge Authentication & Identity") — Netflix Technology Blog, 2021-02-09
114. Trading a Cloud Identity for Your Own: Workload Attestation on Managed Compute — Netflix Technology Blog (Dhruv Pratap), 2026-09-25
115. How Netflix Accurately Attributes eBPF Flow Logs — Netflix Technology Blog, 2025-04-08
116. The Show Must Go On: Securing Netflix Studios At Scale — Netflix Technology Blog, 2021-09-13
117. Netflix/bless — Netflix (GitHub), undated (archival notice in README)
118. Toward A Practical Perceptual Video Quality Metric — Netflix Technology Blog, 2016-06-06
119. More Efficient Mobile Encodes for Netflix Downloads — Netflix Technology Blog, 2016-12-01
120. Dynamic optimizer — a perceptual video encoding optimization framework — Netflix Technology Blog (Ioannis Katsavounidis), 2018-03-05
121. Simplifying Media Innovation at Netflix with Archer — Netflix Technology Blog, 2018-06-20
122. Netflix Now Streaming AV1 on Android — Netflix Technology Blog, 2020-02-05
123. Optimized shot-based encodes for 4K: Now streaming! — Netflix Technology Blog, 2020-08-28
124. Welcome to Open Connect (Open Connect home: "What is Open Connect", "How to get started", "Sample Architectures") — Netflix, undated (page live 2026, © 2026)
125. How Data Science Helps Power Worldwide Delivery of Netflix Content (Andrew Berglund) — Netflix Technology Blog, 2017-05-25
126. Using Machine Learning to Improve Streaming Quality at Netflix (Chaitanya Ekanadham) — Netflix Technology Blog, 2018-03-22
127. Optimizing the Netflix Streaming Experience with Data Science (Nirmal Govind) — Netflix Technology Blog, 2014-06-11
128. Distributing Content to Open Connect (Mohit Vora, Andrew Berglund, Videsh Sadafal, David Pfitzner, Ellen Livengood) — Netflix Technology Blog, 2017-12-12
129. Caching Content for Holiday Streaming (Laura Pruitt) — Netflix Technology Blog, originally 2015-12-01 (Medium repost 2017-04-18)
130. Netflix Live Origin (Xiaomei Liu, Joseph Lynch, Chris Newton) — Netflix Technology Blog, 2025-12-15
131. Simple streaming telemetry (Colin McIntosh, Michael Costello) — Netflix Technology Blog, 2020-11-23
132. Open Connect Appliances (Overview, The Hardware, Software, Security) — Netflix, undated (page live 2026, © 2026)
133. How Netflix Works With ISPs Around the Globe to Deliver a Great Viewing Experience (Ken Florance, VP Content Delivery) — Netflix (About Netflix newsroom), 2016-03-17
134. Serving Netflix Video at 400Gb/s on FreeBSD (Drew Gallatin, EuroBSDCon 2021) — Author-hosted slides (Netflix engineer), 2021 (EuroBSDCon 2021)
135. The "other" FreeBSD optimizations used by Netflix to serve video at 800Gb/s from a single server (Drew Gallatin, EuroBSDCon 2022) — Author-hosted slides (Netflix engineer), 2022
136. The Magical Mystery Merge, Or Why we run FreeBSD-current at Netflix (Drew Gallatin, OpenFest) — Author-hosted slides (Netflix engineer), November 2023
137. Adaptive Bitrate & Congestion Control: Together, they make the Internet a friendlier place (Te-Yuan Huang, "on behalf of many Netflix colleagues", ICCRG, IETF 123 Madrid) — IETF Datatracker (slides by Netflix), 2025-07-21
138. Load-Balancing Netflix Traffic at Global Scale (Niosha Behnam, Sergey Fedorov; transcript) — InfoQ (transcript of Netflix engineers' QCon talk), InfoQ page date Dec 14, 2023
139. FAST.com Internet speed test (Sergey Fedorov, Netflix, RIPE 74 Budapest) — RIPE NCC (slides by Netflix engineer), May 2017
140. Peering with Open Connect (Guidelines, Locations) — Netflix, undated (page live 2026, © 2026)
141. A cooperative approach to content delivery: A Netflix briefing paper 2021 — Netflix, 2021 (data "as of 2020" / "as of early 2021")
142. Netflix Open Connect Deployment Guide (compiles Partner Help Center articles: Requirements for deploying embedded appliances; Summary of the embedded OCA deployment workflow; Network configuration [zendesk 360035533071]; Fill patterns [360035618071]; Automatic Software Updates; Health Monitoring; etc.) — Netflix, "Last Updated: 22 August 2025"
143. Netflix and Fill (Michael Costello, Ellen Livengood) — Netflix Technology Blog, 2016-08-11
144. Content Popularity for Open Connect (Mohit Vora, Lara Deek, Ellen Livengood) — Netflix Technology Blog, 2017-06-20