How Netflix scales, from ~50K viewers to ~250M viewers

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.

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.

What breaks

Every title has to be turned into formats for every kind of device, and that preparation work is running on the same servers that play video — each new release competes with viewers for the same CPU, and the fleet is saturating.

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 switches between them mid-play — so every film has to exist in many renditions. In this simplified step that preparation shares the fleet with playback, so every new release competes with viewers for the same machines and the fleet saturates even though the database is cached. Preparation 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.

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.