You press Play. A spinner spins for a beat, then the show starts. It feels like
one thing talking to one server. It is not. In that half second your request
touched two completely different networks, on purpose, and the split is one of
the cleanest system-design ideas you can steal.
Here is the whole path in one loop:
Two planes, not one server
Netflix splits into a control plane and a data plane, and they run on
different infrastructure for a reason.
- Control plane (AWS). Everything that happens before the picture appears: who are you (auth and membership), what are you allowed to watch, which exact video and audio, and which cache is closest to you. These are small, smart, bursty requests. They run as hundreds of microservices behind an edge gateway (Netflix open-sourced theirs as Zuul) on AWS.
- Data plane (Open Connect). The actual video bytes. Netflix built its own CDN called Open Connect, made of servers called OCAs (Open Connect Appliances) that sit inside ISP networks, physically close to you. The heavy stream comes from there.
The punchline the GIF is built around: the video never streams from AWS.
The play request, step by step
- You → AWS. Hitting Play sends a small request to the control plane: verify the account, check entitlements, pick the stream, and ask the steering service which OCAs are nearest and healthiest for you right now.
- AWS → you. The backend replies with a ranked list of Open Connect URLs. That is the last thing AWS does for this play. It handed you a map, not a movie.
- OCA → you. Your player opens a connection straight to the closest OCA and pulls the video, adapting bitrate to your bandwidth. If one cache degrades, the client can switch to the next URL on the list without asking AWS again.
Why this split is so good
This is not Netflix being fancy. It is separation of concerns applied to a network:
- Different problems, different tools. Decisions are low-bandwidth and need elasticity and fast iteration, so they live on AWS microservices. Bytes are enormous and need to be near the user, so they live at the edge in Open Connect.
- Push the expensive thing to the edge. Serving petabytes from a central cloud would be slow and ruinously expensive. Caching content inside ISPs makes it fast and cheap, and it is why your stream holds up at peak hours.
- Blast radius. Because the planes are independent, a wobble in the control plane does not stop a stream already in flight. Netflix leans into this with stateless services, horizontal scaling, and chaos testing (yes, Chaos Monkey is real, it kills production instances on purpose).
None of this was the original design. Netflix ran a monolith on a single Oracle
database until a 2008 corruption stopped DVD shipping for three days. That outage
pushed them to AWS and microservices, and later to building Open Connect in 2012.
The two-plane shape is what they landed on after the scaling hurt.
The lesson you can actually use
Forget Netflix for a second. Almost every system you build has a control plane
and a data plane hiding in it. The API that decides what to do versus the pipe
that moves the heavy payload. The scheduler versus the workers. The metadata
service versus the blob store.
The highest-leverage move is usually to stop treating them as one thing: let the
"decisions" layer stay small, smart, and elastic, and push the "heavy bytes" layer
as close to the consumer as you can. Once you see the split, you cannot unsee it.
So: in the system you work on, what is the control plane, and what is the data
plane? And are they fighting each other because they are still glued together?
Tell me below.
Diagram and cover made by me. Netflix name and logo belong to Netflix and are used
here for commentary.
Top comments (0)