Real-world system design
How Netflix scales, from one server to a billion users
How a streaming service grows from one datacenter to a quarter of a billion viewers — the story of moving video to the edge, told in AWS terms and based on Netflix's public engineering talks.
Play it — turn the traffic up yourselfStage 1 of 5
Launch (~50K viewers)
- Web clientBrowser / web client
- EC2Amazon EC2
- RDSAmazon RDS
What breaks
Your app server is streaming the video itself, and the bytes are drowning it — one machine cannot push films to everyone at once.
Video is not like a web request: a single film is gigabytes, and every viewer pulls a steady stream of it. Serving those bytes straight from the app server means one machine's CPU and its network link become the ceiling long before the catalogue logic does. Adding features cannot help — the wall is bandwidth.
The fix
A CDN caches each film in edge locations near the viewer, so the bytes are served close to home and never touch your app servers — which are left free to do the light work of browsing and playback control. Netflix took this to its limit with Open Connect, putting its own caching appliances inside ISPs. The object store holds the master files the edge pulls from.
Video is bytes, not requests — serve it from the edge, never from your app servers.
Based on: How Netflix Works: Open Connect and the streaming path (High Scalability, 2017)
Stage 2 of 5
Growth (~2M viewers)
- Web clientBrowser / web client
- CloudFrontAmazon CloudFront
- S3Amazon S3
- ALBApplication Load Balancer
- EC2 Auto ScalingEC2 Auto Scaling Group
- RDSAmazon RDS
What breaks
The video is off the app servers now, but every screen still reads the catalogue from one database — and it is saturating.
Once the CDN carries the bytes, the app tier scales out easily. But every home screen, search and 'continue watching' row reads the catalogue and each viewer's state from the same primary database, and reads outnumber writes many times over. The one database becomes the bottleneck the app tier no longer is.
The fix
A cache holds the hot catalogue and each viewer's recent state in memory, so the great majority of reads are served without touching the database, and a read replica takes the queries that get through. Reads scale sideways, and the primary is left for the writes.
Once the bytes are at the edge, the read database is the next wall — a cache and a replica take it off the primary.
Based on: Completing the Netflix Cloud Migration (Netflix Technology Blog, 2016)
Stage 3 of 5
Every device (~20M viewers)
- Web clientBrowser / web client
- CloudFrontAmazon CloudFront
- S3Amazon S3
- ALBApplication Load Balancer
- EC2 Auto ScalingEC2 Auto Scaling Group
- ElastiCache RedisAmazon ElastiCache for Redis
- RDSAmazon RDS
What breaks
Every device wants a different resolution and format, and the app tier is encoding each stream on the fly — the fleet is saturating on that work.
A phone on a train, a TV on fibre and a laptop on hotel wifi each need a different bitrate and codec, and adaptive streaming means switching between them mid-play. Doing that encoding inside the app tier, per stream, is heavy CPU work multiplied by every viewer — and it saturates the fleet even though the database is cached. The work does not belong on the playback path.
The fix
Every film is encoded into all its bitrates and formats once, ahead of time: the app pushes an encode job onto a queue and a separate fleet of workers produces the renditions and stores them for the CDN to serve. Playback just picks the right pre-made rendition, so the app tier stops encoding and the worker fleet scales on its own.
Encode each film's renditions once in the background — never re-encode on the playback path.
Based on: How Netflix Works: Open Connect and the streaming path (High Scalability, 2017)
Stage 4 of 5
Global (~100M viewers)
- Web clientBrowser / web client
- CloudFrontAmazon CloudFront
- S3Amazon S3
- ALBApplication Load Balancer
- EC2 Auto ScalingEC2 Auto Scaling Group
- ElastiCache RedisAmazon ElastiCache for Redis
- RDSAmazon RDS
- SQSAmazon SQS
What breaks
One region is now serving the whole planet — the streaming services are stretched, and a viewer on another continent waits on a round-trip across the ocean.
A single region has a capacity ceiling and a distance problem at once: the service fleet can only grow so far, and a viewer far from it pays latency on every control request — start, seek, switch quality. Scaling up in one place buys throughput, but it cannot fix distance.
The fix
Geographic routing sends each viewer to the region closest to them, so control requests are served near home and the load splits across regions instead of stacking on one. Netflix runs its services in multiple AWS regions and can steer all traffic out of a failing one; the video itself was already global, on Open Connect at the edge.
At global scale you run the services in every region and route each viewer to the nearest — the video was already at the edge.
Based on: Completing the Netflix Cloud Migration (Netflix Technology Blog, 2016)
Stage 5 of 5
Resilient at scale (~250M viewers)
- Web clientBrowser / web client
- CloudFrontAmazon CloudFront
- S3Amazon S3
- Route 53Amazon Route 53
- API Gateway (REST)Amazon API Gateway — REST API
- EC2 Auto ScalingEC2 Auto Scaling Group
- DynamoDBAmazon DynamoDB
At planetary scale the system is hundreds of small services per region behind a gateway — and each call assumes its dependencies will fail, with timeouts and fallbacks so one slow service never takes playback down with it.
Based on: Fault Tolerance in a High Volume, Distributed System (Hystrix) (Netflix Technology Blog, 2012)
Now try it yourself
Reading is one thing. Turn the traffic up on Netflix's architecture, watch it break, fix it — then build the whole thing from a blank canvas.
Play the scale journey