I used to think the hard part of a video service was the player. Write a good player, buffer ahead a bit, and you are done. Then I started reading about how much work happens before a single frame reaches your screen, and I changed my mind. The player is the easy part. The hard part is getting the right bytes close enough to you that the player never has to wait.
Here is the core problem. A single movie is not one file. It is dozens of files. The same two hours of video gets encoded at many resolutions and bitrates, from a tiny version for a phone on a weak connection up to 4K for a good TV on fiber. Multiply that by a huge catalog and you have a very large amount of data that has to be ready before anyone presses play. Then multiply that by tens of millions of people watching in the evening, all in the same few hours, often the same handful of popular titles. If all of that traffic went back to a central data center, the network would fall over and the cost would be absurd.
The first big design decision is to encode everything ahead of time, not on demand. When a title is added, a pipeline chops it into short segments, usually a few seconds each, and encodes each segment at every quality level. This is expensive to compute, but you only pay it once per title, and encoding quality can be tuned carefully because there is no real time pressure. Netflix goes further and encodes per title and even per scene, so a simple cartoon does not get the same bitrate budget as a fast action scene. The trade-off is storage and pipeline complexity in exchange for lower bandwidth and better picture quality at playback. For a service where bandwidth is the dominant cost, that trade is clearly worth it.
The second decision is where those segments live. This is the part people underestimate. Netflix built its own content delivery network, Open Connect, and placed cache appliances inside internet service provider networks and at internet exchange points. In plain terms, the video sits on a box that is one short hop from your home instead of across the country. Popular titles get pushed to these caches ahead of demand, often overnight when the network is quiet. So when you press play on a popular show, the bytes are already sitting a few milliseconds away. The trade-off is a large physical and operational footprint. You are shipping hardware and coordinating with ISPs, which is not something a small team can copy. But it removes the single biggest bottleneck, which is the long haul network.
The third decision lives in the player after all, but it is a decision about adaptation, not playback. This is adaptive bitrate streaming. The player watches your download speed and its own buffer, and it picks the quality of the next segment based on current conditions. If your connection dips, the next few seconds arrive in a lower quality version rather than stalling. If things improve, it steps back up. Because every segment already exists at every quality level, switching is just a matter of requesting a different file for the next chunk. The user sees quality shift a little. They almost never see a spinner. That is the whole point. People forgive a slightly softer image far more than they forgive a pause.
There is a control layer around all of this that is easy to forget. Something has to answer "what should this user watch next," "is this account allowed to stream right now," and "which cache should serve this request." That control plane runs in the cloud and is mostly small API calls and metadata. It is separate from the heavy video path on purpose. The bytes flow from caches near you. The decisions flow from central services. Keeping those two planes separate is what lets each scale on its own terms.
How does the real company do it in practice? Netflix runs its control and application logic on cloud infrastructure and pushes the actual video through Open Connect, its own CDN embedded in ISP networks. Titles are encoded once, per title and per scene, into many bitrate ladders. Popular content is pre positioned to edge caches before the evening rush. The player handles adaptation. The pattern that keeps showing up is the same one worth stealing: pre compute the expensive work, store many variants, and move the data as close to the user as you can afford.
If you are studying this for an interview, the trap is spending all your time on the player and the database. The real answer is encoding strategy plus CDN placement plus adaptive bitrate, and being honest about the storage and operational cost that buys you.
I wrote the full breakdown, with diagrams and the data model, here: https://www.systemdesign.academy/interview/design-netflix
Top comments (0)