Netflix isn't running the architecture most developers remember.
The company that became famous for Eureka, Hystrix, Ribbon, Zuul and Titus has spent years replacing, reshaping, or moving responsibilities out of those systems. Today, its publicly described architecture is a combination of EKS, Envoy-based service networking, Open Connect, federated APIs, specialized storage abstractions, modern video codecs, recommendation systems, and increasingly sophisticated AI infrastructure.
That's what makes Netflix interesting from an engineering perspective. The important story isn't one magical "Netflix stack." It's how the architecture keeps changing when the scale, failure modes, or organizational constraints change.
The shape of it
One important distinction gets lost in many simplified diagrams: Netflix's streaming data plane and application/API plane are separate paths.
Streaming data plane
flowchart LR
U["Client: TV, phone, browser, console"]
U -->|playback request| ST["Steering Service"]
ST --> OCA["Open Connect"]
OCA -->|video segments| U
Application and control plane
flowchart TB
U["Client: TV, phone, browser, console"]
U -->|API requests| G["Federated GraphQL / API Layer"]
G --> DGS["Domain Graph Services"]
DGS --> MS["Services on EKS"]
MS --> DA["Data Abstractions"]
DA --> C["Cassandra / other stores"]
DA --> E["EVCache / other caches"]
MS --> K["Kafka / event streams"]
K --> ML["Recommendation and ML systems"]
Both diagrams are intentionally simplified. Netflix runs many individual services and infrastructure components behind each box.
The key point is that pressing Play does not mean your video travels through GraphQL, then through a database, and finally comes back from a microservice. The API/control systems help coordinate the experience; Open Connect handles the actual video delivery path.
It started with a broken database
Netflix's cloud journey didn't begin with a grand strategy — it began with a three-day outage.
In August 2008, a corrupted Oracle database disrupted Netflix's DVD-shipping business for three days. At the time, Netflix was operating a conventional data-center architecture, with a major dependency on vertically scaled relational databases.
That failure pushed Netflix toward a much bigger bet: move to the public cloud and redesign the application around distributed services.
The migration began in 2009 and took roughly seven years, completing in January 2016. Netflix did not simply lift its existing application into AWS. It progressively decomposed major parts of the system and rebuilt them around services designed to scale horizontally and tolerate infrastructure failures. Netflix: Completing the Cloud Migration
A second incident, involving AWS infrastructure failures around Christmas 2012, reinforced another lesson: cloud infrastructure itself could fail.
That forced Netflix to think beyond individual application failures and design for failures involving infrastructure components, availability zones, and eventually entire regions.
That's the backdrop for much of the resilience and deployment engineering that followed.
The famous Netflix OSS stack evolved, rather than simply disappearing
If you've studied microservices patterns, you've probably encountered Netflix's original OSS stack:
Eureka for service discovery, Ribbon for client-side load balancing, Hystrix for circuit breaking, and Zuul for edge routing.
These projects were built for a particular moment: a large Java fleet running on AWS, where application-embedded libraries solved networking and resilience problems that the wider cloud ecosystem had not yet standardized.
Then the architecture evolved.
Hystrix and Ribbon entered maintenance mode. Zuul 1 was followed by Zuul 2, which moved toward an asynchronous, non-blocking architecture. Meanwhile, Netflix shifted more service-to-service networking responsibilities into an Envoy-based service-mesh architecture. Spring Cloud Netflix: Modules in Maintenance Mode
But Eureka should not be grouped with those retired components.
Netflix's service-mesh architecture has continued to use Eureka's service-discovery information as an input to its mesh control plane. Envoy handles networking at the proxy layer; Eureka remains part of the service-discovery story. In other words, Netflix did not simply replace Eureka with Envoy. Netflix: Zero Configuration Service Mesh with On-Demand Cluster Discovery
The stack, then and now
Concern | Earlier Netflix approach | More recent direction |
|---|---|---|
Service discovery | Eureka | Eureka integrated with mesh control-plane systems |
Client-side load balancing | Ribbon | Envoy / mesh-based networking |
Circuit breaking / overload protection | Hystrix and application logic | Adaptive concurrency and service-level resilience |
Edge routing | Zuul 1 | Zuul 2 and newer networking layers |
Service-to-service networking | Client libraries | Envoy-based service mesh |
The lesson isn't "don't use Netflix OSS."
It's that even Netflix treats infrastructure components as replaceable implementations of longer-lived engineering concerns.
Service discovery stays important. Routing stays important. Fault isolation stays important. Load management stays important.
The tools can change.
Containers: Netflix's 2025 move from Titus to EKS
Netflix built its own container orchestration platform, Titus, rather than adopting early Kubernetes.
That was a reasonable decision at the time. Titus was built around Netflix's own operational requirements and gave the company deep control over scheduling, EC2 capacity management, networking, and large-scale workloads.
Titus carried Netflix workloads for years.
Then, in 2025, Netflix migrated its container fleet to Amazon EKS.
The scale is remarkable. AWS says Netflix now runs fewer than 20 production clusters across four regions, with individual clusters reaching roughly 10,000 large instances and 80,000 pods. During peak events, Netflix may need to launch around 70,000 containers in five minutes. AWS also says the migration followed about nine months of preparation, with the fleet moved in a single quarter.
The interesting lesson isn't "Kubernetes won."
It's that the operational systems Netflix built around Titus — capacity management, disruption budgets, automation, and fleet-wide practices — mattered more than the scheduler underneath them.
Those practices survived the platform migration.
That is a useful lesson well beyond Netflix:
Good infrastructure practices should survive a change of infrastructure.
Shipping code without breaking things
Continuous delivery at Netflix runs on Spinnaker, the open-source multi-cloud deployment platform Netflix began developing around 2015 and later developed with Google and the wider community.
Spinnaker turns a deployment into a controlled pipeline: build an artifact, run required checks, deploy to a limited population, measure the result, and progressively promote the change when its health looks acceptable.
Netflix has also pushed the idea further with Managed Delivery, where teams express desired deployment state and policy instead of manually assembling every deployment step.
That fits a larger evolution in infrastructure:
Move from imperative instructions toward declarative intent.
Rather than telling a platform exactly how every deployment should happen, teams describe what must be true for a deployment to be considered safe.
The platform can then work out the path.
Making sense of the data
Netflix doesn't run one database — it runs many, behind abstractions designed to keep application teams from having to understand the implementation details of every storage system.
Netflix has described a Data Gateway approach that exposes purpose-built storage APIs rather than making every application directly dependent on a particular persistence technology.
Different workloads can therefore use different physical storage systems underneath.
Those systems have included Cassandra, DynamoDB, RocksDB, Elasticsearch, CockroachDB, and relational databases for workloads where transactional guarantees matter more than extreme horizontal scale.
The point is not that Netflix found one "best database."
It did almost the opposite.
It created ways for teams to use storage according to the workload rather than forcing every service into the same persistence model.
A simplified conceptual example — not a Netflix configuration — might look like this:
namespace: user-watch-progress
consistency: read-your-writes
storage:
durable_store: cassandra
cache: evcache
One recurring pattern is separating durable storage from high-speed caching. EVCache, Netflix's Memcached-based caching layer, can absorb large read volumes while systems such as Cassandra handle durable writes.
Netflix's Real-Time Distributed Graph shows what this looks like at extreme scale. Netflix has publicly described a graph containing more than 8 billion nodes and 150 billion edges, backed by about a dozen Cassandra clusters and capable of sustaining millions of reads and writes per second.
The broader lesson is simple:
Scale the hot path independently from the durable path when the workload demands it.
One graph to power many APIs
Netflix's API layer went through its own evolution.
Earlier in the architecture, client teams — iOS, Android, TV, web and others — could build their own backend-for-frontend logic using Falcor, Netflix's data-fetching technology, behind the edge layer.
That worked technically, but organizational growth created another problem: different client teams could end up rebuilding similar aggregation logic in slightly different ways.
Netflix's later GraphQL Federation architecture attacked that problem by allowing backend teams to own domain-specific pieces of a larger graph.
Individual Domain Graph Services (DGS) can own their piece of the schema, while the federated platform composes those domains into a unified graph that clients can query. Netflix: How Netflix Scales Its API with GraphQL Federation
The important benefit isn't simply "GraphQL instead of REST."
It's organizational:
Teams can own their slice of the API while clients still see one coherent interface.
That becomes increasingly valuable when the organization, not just the traffic volume, becomes the scaling problem.
Getting the bits to your screen
Open Connect is Netflix's purpose-built content-delivery network, and it works differently from a conventional centralized CDN.
Netflix places servers close to viewers, including directly inside ISP networks, so popular content can be served locally instead of repeatedly traveling across long-distance network paths.
Netflix has publicly described Open Connect at a scale of roughly 18,000 servers across 6,000 locations in 175 countries.
Those figures matter because they are often misstated as "6,000 appliances." The publicly reported numbers are servers and locations.
The playback flow is intentionally simple:
A client requests playback.
A Steering Service determines an appropriate delivery location.
The client streams video segments from Open Connect.
The more interesting part is what happens when central connectivity fails.
Netflix has designed Open Connect so that the control plane and data plane can fail somewhat independently. An appliance that loses contact with central Netflix systems can continue serving content it already has rather than becoming immediately useless.
That's a powerful resilience principle:
When the control plane disappears, the data plane should continue doing useful work whenever possible.
Netflix has also described Open Connect as helping avoid sending every byte of streaming traffic through its own cloud infrastructure.
Squeezing more picture into fewer bits
Encoding is where a large part of Netflix's infrastructure investment quietly turns into lower bandwidth requirements and better playback.
Per-title encoding stopped treating every movie and episode as though it needed the same bitrate ladder. A dialogue-heavy drama, a dark film, and a fast-moving action sequence can have very different compression characteristics.
Netflix's subsequent encoding research reported substantial bitrate reductions from content-aware encoding approaches, including later improvements that reduced average bitrate by more than 20% in tested pipelines while maintaining comparable perceived quality.
The current frontier is AV1.
By late 2025, Netflix reported that AV1 represented roughly 30% of all Netflix viewing, making it the company's second-most-used codec and putting it on track to become number one. Netflix: AV1 Now Powering 30% of Netflix Streaming
One particularly interesting development is Film Grain Synthesis.
Film grain is expensive to encode because it behaves a lot like noise: tiny variations appear throughout the image and are difficult to compress efficiently.
Instead of encoding all of that grain literally, Netflix can remove much of it before encoding and send information that allows the decoder to reconstruct a convincing approximation.
The savings can be dramatic on the right content.
In one Netflix example involving heavily grainy footage, Film Grain Synthesis reduced bitrate from roughly 8.3 Mbps to 2.8 Mbps, about a 66% reduction, while producing better-looking grain than the conventional AV1 encode.
That should be understood as a specific example, not a universal 66% saving across Netflix's catalog.
Netflix also uses VMAF, its perceptual video-quality metric, to evaluate whether lower bitrate still produces acceptable visual quality.
That's an important distinction.
A smaller file is only an improvement if the viewer can't tell that quality was lost.
Breaking things on purpose
Netflix popularized chaos engineering with Chaos Monkey in 2010.
The idea was deliberately uncomfortable: randomly terminate production instances during normal operation so engineers would discover weak assumptions before a real infrastructure failure exposed them.
The philosophy changes the question from:
"What happens if this server dies?"
to:
"Have we proved that our system can survive when this dependency disappears?"
Netflix later extended the idea with Chaos Kong, which tested failure scenarios involving entire AWS regions.
The resilience discipline has also expanded beyond chaos experiments.
More recent Netflix reliability work emphasizes prioritized load shedding: when traffic threatens to overwhelm a service, lower-value requests should be rejected or delayed before higher-value requests are harmed.
A background synchronization job and a request to start playback do not have equal business value.
A resilient system should know that.
The stress test: live sports and events
Nothing exposes architecture gaps like a live event with a hard start time and no opportunity to spread the load gradually.
In November 2024, Netflix's live exhibition boxing match between Mike Tyson and Jake Paul attracted an estimated 108 million live global viewers and peaked at 65 million concurrent streams. The event also generated substantial public complaints about buffering and interruptions.
The event mattered because live streaming behaves differently from on-demand playback.
Millions of people can suddenly request content at roughly the same time.
Netflix's later NFL broadcasts provided another major test. By Christmas 2025, the Lions-Vikings game averaged 27.5 million U.S. viewers, peaked above 30 million during the halftime show, and reached a 30.5 million global average minute audience.
Netflix has also described improvements to its live-video origin architecture, including separation of read-heavy and write-heavy paths and priority-based rate limiting so lower-priority work does not crowd out traffic needed for real-time playback.
That pattern is bigger than sports:
When workloads compete, protect the requests that matter most instead of treating every request equally.
Teaching the algorithm
Netflix's personalization architecture has also evolved from collections of narrowly focused models toward more unified approaches.
Different recommendation surfaces historically relied on specialized models. One system could rank a homepage row while another ranked search results or helped determine when to send a notification.
More recent Netflix research has described Hydra, a multi-task learning approach that consolidates related personalization and ranking objectives around shared representations instead of maintaining every task as a completely isolated model.
That does not mean Netflix replaced every recommendation system with one giant model.
The useful architectural lesson is narrower:
Share learned representations and infrastructure when multiple ML tasks are solving closely related problems.
The benefit is not just model quality. It can also reduce the operational cost of training, deploying, and maintaining many separate systems.
Serving AI models in production
Serving AI models at Netflix's scale requires infrastructure of its own.
Netflix's AI infrastructure work initially evaluated and used TensorRT-LLM together with Triton. As workloads expanded beyond straightforward text generation to include ranking, retrieval, and embedding workloads, Netflix benchmarked alternative serving systems and moved toward vLLM as a default inference engine for its paved-path serving architecture.
That's another useful Netflix pattern.
The company is famous for building its own infrastructure, but it doesn't build everything merely for the sake of ownership.
When an open-source project becomes capable enough to satisfy the workload, adopting it can be the better engineering choice.
Sometimes the best infrastructure decision is not to build another internal platform.
What developers can actually steal from Netflix
Most teams will never operate at Netflix's scale, and copying Netflix's exact tools would be a mistake.
Titus and Open Connect exist because of constraints most companies simply don't have.
The patterns underneath them travel much better than the products themselves.
Tools are disposable; the problems they solve aren't.
Netflix has changed its implementation of service discovery, routing, resilience, and scheduling without abandoning those underlying concerns.
Separate read and write paths when they need to scale independently.
EVCache and Cassandra are one example of a broader principle: don't force radically different workloads through the same bottleneck.
Decouple control planes from data planes where failure is expensive.
Open Connect can continue serving cached content even when central control connectivity is impaired.
Practice failure before it practices on you.
Chaos engineering turns catastrophic surprises into rehearsed scenarios.
Boring technology is still the right call somewhere.
A transactional workload doesn't become better simply because its database sounds more sophisticated.
Give teams ownership of their API domains.
Federated GraphQL is valuable not because GraphQL is magical, but because API ownership can scale with the organization instead of funneling every change through one central team.
Protect high-value traffic first.
Prioritized load shedding is useful anywhere a sudden traffic spike can turn "everything is slow" into "everything is down."
The architecture keeps changing
If you remember one thing about Netflix's architecture, make it this:
There is no single timeless "Netflix stack."
The company moved from a conventional data center to AWS, from a monolithic system toward distributed services, from application-embedded resilience libraries toward service-mesh infrastructure, from Titus to EKS, from conventional content delivery toward a deeply distributed Open Connect network, and from collections of specialized ML systems toward increasingly shared AI infrastructure.
The individual technologies will keep changing.
The engineering constraints won't:
scale, failure, latency, organizational ownership, and cost.
That's the part worth copying.
Further reading
Netflix Technology Blog — the primary source for Netflix's engineering work.
Zero Configuration Service Mesh with On-Demand Cluster Discovery
This post draws on Netflix's public engineering blog, company publications, AWS material, and reporting that covers those sources. It is not an official Netflix publication. Infrastructure figures are snapshots of publicly reported systems and can change over time.
Comments (0)
Login to post a comment.