How Netflix scaled its backend
Designing for failure instead of hoping it won't happen
Netflix runs a globally distributed system of hundreds of microservices, streaming to hundreds of millions of devices. At that scale, on public cloud infrastructure, something is failing somewhere at almost every moment - a single "keep everything up" strategy isn't realistic.
Netflix streams to a subscriber base spread across nearly every country it operates in, on devices ranging from smart TVs to phones to game consoles, and it runs almost entirely on AWS rather than its own data centers - one of the largest public examples of a company running effectively its whole product on someone else's cloud.
Interactive
Netflix’s stack, mapped
Grouped by where each piece sits in the request path. Click through to see what each one is actually for.
Infrastructure
Edge & delivery
Services & language
Data & messaging
Cloud provider
·AWS (Amazon Web Services)
Netflix's applications, databases, and storage run almost entirely on AWS's public cloud rather than Netflix-owned data centers - they rent the compute and let AWS handle the physical hardware.
Click a piece of Netflix’s stack to see what it’s for
The same stack, in plain language
AWS (Amazon Web Services)
Cloud provider
Netflix's applications, databases, and storage run almost entirely on AWS's public cloud rather than Netflix-owned data centers - they rent the compute and let AWS handle the physical hardware.
Open Connect
Custom CDN
Netflix built its own content delivery network - physical caching servers placed directly inside internet service providers' networks around the world - specifically so the actual video files (the heaviest part of the traffic) don't have to travel far to reach a viewer.
Java / JVM
Backend language
The majority of Netflix's backend microservices are written in Java, running on the JVM (Java Virtual Machine) - a mature, high-performance runtime well suited to the large number of long-running backend services Netflix operates.
Spring Boot
Application framework
Many Netflix Java services are built on Spring Boot, a framework that handles a lot of the repetitive setup (web server, configuration, dependency wiring) so teams can focus on the actual service logic.
Cassandra
Database
A NoSQL database Netflix uses for data that needs to be written and read at very high volume across many regions, where strict relational consistency matters less than always being available, even during a regional outage.
EVCache (built on Memcached)
Caching layer
Netflix's caching layer, built on top of Memcached, used to avoid hitting slower backend datastores for data that's read far more often than it changes - user session data, frequently accessed metadata.
Kafka
Event streaming
Used to move large volumes of event data (like viewing activity and operational metrics) between services asynchronously, so producers and consumers of that data don't have to be directly connected or available at the same time.
Zuul
API gateway
Netflix's own edge gateway service - the front door that every request passes through first, responsible for routing it to the right internal microservice and applying cross-cutting rules like authentication.
Deep dives
How Netflix built a real-time graph of what its members are doing
Turning millions of scattered events per second into one connected picture, as it happens
How Netflix queries a billion-edge graph in under 100 milliseconds
Turning a constantly growing graph into answers that feel instant, no matter how the question is shaped
How it actually works
Chaos engineering, on purpose
Netflix popularized deliberately injecting failure into production systems to find weaknesses before they cause real outages. Their original tool, Chaos Monkey, randomly terminates instances in production - the idea being that if your system can't survive a random instance dying, you'll find out on your own schedule instead of during a real incident. This grew into a broader practice (the 'Simian Army') testing for everything from single-instance failure to entire-region outages. In plain terms: instead of hoping their servers never crash, Netflix built a robot that crashes them on purpose, constantly, so every team is forced to build services that survive it.
Microservices, split around team and failure boundaries
Netflix moved from a monolithic architecture - one large application handling everything - to a large number of independently deployable microservices, each owned by a small team, communicating over the network rather than through shared in-process code. Concretely, this means the service that recommends what to watch next, the service that handles billing, and the service that actually streams video are all separate programs, running on separate machines, that talk to each other over the network instead of being one giant program. This let teams ship independently, but the real architectural point was isolating failure - one misbehaving service shouldn't be able to take down the services around it.
Falling back gracefully instead of falling over
A recurring theme in Netflix's public engineering writing is designing every service to degrade rather than fail outright when a dependency is slow or unavailable - showing a simpler recommendation list instead of an error page, for instance. Netflix's Hystrix library (since retired in favor of newer resilience patterns) was built specifically to add circuit breakers - a mechanism that stops calling a struggling service temporarily, the same way an electrical circuit breaker cuts power before something overheats - and fallback logic around calls to other services.
Open Connect: solving video delivery as its own problem
Streaming video is enormous in volume compared to normal web traffic - a single popular show being watched by millions of people at once is a fundamentally different delivery problem than serving a webpage. Rather than relying entirely on general-purpose CDNs, Netflix built and placed its own caching hardware (Open Connect Appliances) physically inside ISP networks, so the video itself is served from a server close to the viewer instead of traveling across the wider internet for every single stream.
What “microservices” means here, concretely
"Microservices" at Netflix isn't a buzzword - it concretely means hundreds of small, independently deployable Java/Spring Boot services (recommendations, billing, playback, search, and many more), each with its own team, its own deployment schedule, and its own database where needed, all coordinated through the Zuul gateway and communicating over the network rather than sharing code directly.
Takeaway
The throughline across Netflix's public architecture writing isn't a specific technology - it's the assumption that failure is guaranteed, so the job is limiting its blast radius and testing that containment continuously, not just hoping it holds.
Based on
- Netflix Technology Blog - chaos engineering and the Simian Army
- Netflix Technology Blog - microservices and API gateway evolution
- Netflix Technology Blog - Open Connect CDN architecture
More profiles
Uber
A dispatch problem that's really a real-time geospatial problem
Discord
Millions of concurrent WebSocket connections, and the language choices that followed
Stripe
Money can't be 'probably correct' - reliability as the actual product
Airbnb
Breaking apart a Ruby on Rails monolith without breaking the business
Spotify
Hundreds of autonomous services, and the cloud migration that took years