Design Netflix (video streaming + CDN)

Understanding the problem

"Design Netflix" is the flagship system design prompt in the loop. It is sometimes phrased as "design a global video-streaming service" or narrowed to "design a CDN like Open Connect." One design touches almost everything the round scores. There is a catalog people browse and a heavy ingest-and-encode pipeline run once per title. There is a read path that dwarfs the write path by orders of magnitude. And there is a global delivery story that is the genuine Netflix differentiator. The interviewer usually lets you set the scope, then pushes hard on one piece, and at Netflix that piece is often availability.

Anchor on the numbers first. Netflix serves on the order of hundreds of millions of subscribers across the world, and the catalog is in the low tens of thousands of titles. A title is ingested once and then streamed to millions, so reads beat writes by a margin that is hard to even write as a ratio. The bytes moved are almost entirely video, and Netflix is famously responsible for a large share of internet downstream traffic during peak hours. State the read-versus-write skew up front, because the design lives or dies on serving the same pre-encoded bytes from as close to the viewer as possible.

The Netflix angle

Three things bend this prompt toward Netflix. There's usually no diagramming tool, so rehearse narrating an architecture in words and asking your clarifying questions before a single box exists. Streaming is Netflix's own product, and the person across the table may have helped build Open Connect, so hand-waving gets caught fast. And availability gets probed harder here than almost anywhere. Get the working design out quickly, then spend the rest of your time on what breaks: a region browning out, a title going hot on release night, a dependency timing out.

Functional requirements

Propose a tight scope and give the interviewer room to redirect. The core is short. A viewer browses and searches the catalog, starts playing a title, gets a quality that adapts to their connection, and can stop on one device and resume on another. Everything else can be named and skipped.

Non-functional requirements

These are load-bearing for streaming. Put a number on each before moving on. Read scale comes first: the system serves a massive, globally distributed read load, and playback bytes are the overwhelming majority of it. Startup latency matters next. A viewer who waits more than a second or two for a title to start is a viewer who leaves. So we serve pre-encoded files from somewhere physically near them. Playback has to stay smooth even when the connection wobbles or a freshly released title spikes traffic, which means adapting quality on the fly rather than buffering. And availability sits above all of it. Watching has to keep working even when pieces of the system are degraded, because reads are the product.

Two relaxations matter here, and both pay off later. The catalog can be eventually consistent: if a new title takes a few seconds to appear in everyone's browse view, nobody is harmed, which buys cheap, heavily cached reads. And resume position can be approximate and slightly delayed, so we can write it asynchronously instead of blocking playback on it. Both are availability trades. We would rather serve a slightly stale catalog than fail a browse, and rather lose the last few seconds of resume position than stall a stream.

• ~Hundreds of M Subscribers. Global, mostly evening-peaked.
• ~Low tens of K Catalog titles. Ingested once, streamed to millions.
• Read ≫ write Traffic skew. Why delivery dominates.
• Famously ~15% Of peak internet. Reported share of downstream bytes.

The set-up

Core entities

Name the handful of objects the system moves around before drawing anything. Four carry the design:

The bytes, raw masters and encoded renditions, live in object storage. The small metadata, the Title and Rendition rows, lives in a database that holds nothing but pointers into that storage plus a little status. Each side is bad at the other's job. A database buckles under multi-gigabyte binary rows it was never built to hold. Object storage is built for exactly that: huge write-once files, stored cheaply, replicated for durability, streamed back on demand. But object storage cannot answer "give me the action titles available in Germany," and the metadata can. The catalog is small, in the low tens of thousands of titles, so it fits comfortably in a relational store. Postgres is the name everyone in the room knows. Resume positions and watch history are a different shape: tiny writes from hundreds of millions of profiles, read back per profile, with availability prized over strict consistency. That belongs in a wide-column store like Cassandra, partitioned by profile id, which Netflix leans on heavily for exactly this kind of write-available, globally replicated state.

API

The viewer-facing API is thin, and it never streams video bytes itself. It returns catalog data, and for playback it hands back a manifest plus a steering decision: a list of nearby servers to pull the bytes from. The bytes come from those servers, not from the API.

The POST /play response is the heart of the design. It does not return video. It returns a manifest URL and a short list of servers the client should stream from, chosen for this viewer right now. The bytes flow from those servers, which sit in a completely separate part of the system than the API. The next section makes that split explicit.

High-level design

Take the functional requirements one at a time, sketching the plainest design that works before reaching for anything fancier. The Netflix-defining structure is a split into two planes. The control plane runs in the cloud (on AWS) and is the thinking part. It handles auth, the catalog, search, the playback API, and the steering decision about which server a viewer should stream from. The data plane is Open Connect, Netflix's own content delivery network, and it is the heavy part. It stores the encoded video and serves the actual bytes from boxes physically close to viewers. The control plane decides, the data plane delivers. Color in the diagram tracks what each piece does: blue for people, violet for control-plane services, amber for queues and pipelines, and green for storage and the CDN. The walkthrough keeps the same scheme.

1) Browse and search. The Viewer's client hits the Playback API, which reads the Catalog DB and returns the home rows or search results. The catalog is small and read far more than it is written, so these reads come off cached copies. A new title appearing a few seconds late for some viewers is fine. Almost nothing here is hard at this scale. The interesting problems are downstream, so we keep this path simple and move on.

2) Ingest and encode a title. A Studio master enters the Transcode pipeline. The pipeline encodes it into a ladder of renditions spanning many resolutions and bitrates in several codecs. It packages the output into short streaming segments plus a manifest, writes all of it to the Encoded store, then flips the title to available. This is the entire write path for a title, and it happens once. Putting it behind an asynchronous pipeline lets the heavy CPU work take as long as it needs without touching any viewer. The catch we size in the first deep dive is that this encoding is enormously expensive, because every title becomes a whole matrix of outputs.

3) Start playback. The viewer presses play, and the Playback API authorizes the request and asks the Steering service which servers this viewer should stream from. Steering returns a ranked list of Open Connect appliances, the CDN boxes nearest this viewer that hold the title. The client then reads the manifest, which lists every rendition and its segments, and pulls short segments straight from the top appliance on its list. The control plane decided; the data plane delivers. We are punting two big questions. Why Netflix runs its own CDN at all is deep dive two. How the player picks a rendition and adapts it mid-stream is deep dive three.

4) Resume across devices. As the title plays, the client periodically fires PUT /sessions/{id}/position with where the viewer is, fire-and-forget, answered 202 before anything is durably stored. The position lands in the profile's resume state in Cassandra. When the viewer opens the same title on another device, the client reads that position back and starts there. We already decided this can be approximate and slightly delayed, so it rides off to the side of playback and never blocks a stream. The hardest problem of all is keeping every one of these paths up under release-day spikes and partial failures. That is the last deep dive, and the one Netflix cares about most.

Technology choices

So far each box is only a category. In the room you name a concrete technology for every one and stand behind it. Netflix interviewers favor failure questions: what happens when a region goes dark, an appliance falls over, or a dependency starts timing out. Below is each pick, the reason that category fits, and how the design holds up when it breaks.

• The Playback API and Steering service run as stateless services behind an API gateway on AWS. No instance holds anything a request needs, so any box can serve any call and a dying one simply drops out of rotation. Netflix runs its edge gateway as a fleet of these (the open-source one is Zuul), and the resilience deep dive returns to how a gateway plus per-dependency isolation keeps one slow service from taking the whole API down.
• The Catalog DB is Postgres. The catalog is small, tens of thousands of titles, and read far more than written, so a single primary with read replicas easily carries it. Browse and search read from the replicas, and a few seconds of replication lag is exactly the catalog staleness we already accepted. If the primary fails, a replica is promoted; reads keep flowing the whole time because they were never hitting the primary anyway.
• Resume positions and watch history live in Cassandra, partitioned by profile id. The access pattern is a flood of tiny writes from hundreds of millions of profiles, each read back per profile, and availability matters more than strict consistency. Cassandra is write-available and multi-region by design: a write succeeds against a few replicas and propagates, so a node or even a region loss never blocks saving a position. Losing the last few seconds of resume on a crash is the harmless trade we already named.
• The Encoded store is S3. Object storage is cheap per byte and replicated across zones, so a dead disk or a dead datacenter loses nothing, and it is built for exactly these huge write-once files. Because it is the origin that fills the CDN, its durability is effectively the whole system's durability. Viewers do not read from it directly; the appliances pull from it during fill, which keeps origin egress low and predictable.
• The Transcode pipeline is an asynchronous job system: work lands on a queue (SQS-style) and an autoscaled fleet of encoders (FFmpeg in practice) drains it. A queue hands each job to one worker and hides it rather than deleting it, so when an encoder dies mid-job the work reappears and another worker retries. Because re-encoding overwrites the same output the retry is harmless. A corrupt master that crashes every worker it touches gets parked on a dead-letter queue for inspection instead of cycling forever.
• The Open Connect appliances are Netflix's own CDN, not CloudFront or Akamai. Two properties make video unusually CDN-friendly. An encoded segment never changes once written, so an appliance can hold it indefinitely without ever serving a stale copy. And popularity is concentrated, so a small slice of the catalog answers most requests. When an appliance fails, the client just falls to the next server on its steering list. Deep dive two is the full case for building this rather than renting it.

Two stores here, for two different reasons, and saying both plainly beats forcing one to do everything. The catalog wants a relational store, because browse and search ask structured questions. Resume state wants a write-available wide-column store, because it is a firehose of tiny per-profile writes where staying up beats being perfectly consistent. The brand matters less than the defense: "an S3-style object store" is fine when you can say why the category fits.

Potential deep dives

This is where the round is won or lost. The interviewer picks one or two pieces and pushes until something breaks. Below are the four it reaches for most, ordered by how central each is to the Netflix story and graded against the tiers you are scored on.

1) How do we ingest and encode a title at this quality?

Size it before solving it. A studio master is a very large, high-quality file, and a single title becomes a whole matrix of outputs. Take a rough cut. Roughly five resolutions, each at a couple of bitrates, across three codecs. That is H.264 for universal playback, plus VP9 and AV1 for the devices and titles that can use them. Then add audio tracks and subtitles in many languages. That is dozens of encoded renditions per title before you count languages. Encoding is CPU-heavy and often slower than real time, so a two-hour movie can be many hours of compute per rendition. Multiply that across the matrix and a single title is a large parallel job. But the good news is real. This is the write path, and we already decided it can be expensive. It runs once and serves millions.

The length of a single job is what breaks this. We want a title to finish in the time of its slowest piece, not its full runtime, and a dying worker to cost one small chunk rather than hours.

The Netflix angle

Encode efficiency is a real obsession here. Netflix pioneered per-title and per-shot encoding and bet early on AV1, all to push more quality through fewer bytes, and every percent of bitrate shaved off multiplies across billions of streamed hours. You don't need to recite any of that. Treat the rendition matrix as a cost dial: encode the universal codec for the whole catalog, then spend the expensive codecs only where the views are. That saving lands straight on the egress bill, which is the thing the entire CDN exists to hold down.

The async processing lesson covers the queue and worker mechanics underneath the pipeline.

2) Why does Netflix run its own CDN, and how does Open Connect work?

Start with the scale that forces the decision. Netflix streams an enormous, mostly video, read load, concentrated in the local evening, and it is famously reported to be around 15 percent of internet downstream traffic at peak. Renting all of that from a third-party CDN like CloudFront or Akamai would be staggeringly expensive at this volume. It would also put Netflix's most important property, smooth playback, at the mercy of someone else's capacity and someone else's failures. So Netflix built Open Connect, its own CDN. But the fact that it built one is not the interesting part. Two design choices are. Where the boxes sit, and how content gets onto them.

Pull-through is reactive, and Netflix's traffic is predictable enough to get ahead of. Tomorrow night's popular titles are knowable today, so there is no reason to wait for a cache miss to load them.

The Netflix angle

Open Connect is the system, and the interviewer may have built it. Two ideas carry the answer: embed the boxes inside ISPs, and fill them proactively instead of pulling through. The distinction matters. A normal CDN caches reactively on the first miss. Open Connect predicts demand and pre-positions content during off-peak windows, which is why a launch doesn't melt the origin. Say "pull-through CDN" and stop, and you've described any CDN. "Predict tonight's popular titles per region and fill the ISP-embedded appliances overnight" is the Netflix one.

The scaling reads lesson generalizes caching tiers and CDN strategy beyond streaming.

3) How does the player get smooth playback on a shaky connection?

Playback has to start fast and never stall, on connections that swing from fiber to a weak cellular signal mid-episode. That is why we encoded a ladder of renditions in the first place. The mechanism is adaptive bitrate streaming, or ABR. The key idea to make explicit is the same control-plane and data-plane split as everything else. AWS decides where to stream from. The player decides which rendition to pull, segment by segment, from the appliance.

Concretely, when the viewer presses play, the Playback API and Steering service on AWS return a manifest and a ranked list of Open Connect appliances. The manifest is a standard streaming playlist (HLS .m3u8 or DASH .mpd) listing every rendition and breaking each into short segments, a few seconds of video each. From that point the control plane is out of the loop. The player streams segments straight from its chosen appliance. Now it makes one decision over and over: which rendition to request next.

The connection changes mid-playback, so the quality decision has to change with it, continuously, and without ever letting the buffer hit zero.

The Netflix angle

Be explicit about who decides what. The control plane on AWS makes the playback decision: authorize, return the manifest, steer to appliances. The data plane delivers the bytes. The client drives quality. One clean way to put it in the room: AWS decides where you stream from, the Open Connect appliance hands over the bytes, and your player decides how good those bytes look right now. Draw that boundary cleanly instead of smearing playback logic across one fat service, and the rest of the design falls into place behind it.

The real-time updates lesson covers streaming delivery patterns beyond video.

4) How do we stay up under release-day spikes and partial failure?

This is the deep dive Netflix cares about most, and the one the round circles back to. Picture a hit title dropping at the same evening hour worldwide. Traffic spikes many times over. Dozens of microservices in the control plane sit in the call path of a single play request. At this scale something is always partially broken. An instance is slow, a dependency is timing out, a region is degraded. The requirement is blunt. A failure in one piece must never cascade into "Netflix is down." We design for failure as the normal case, an everyday event the system absorbs.

The Netflix angle

Failure is the main event here, not the epilogue. Netflix invented or popularized most of this vocabulary: Hystrix circuit breakers, chaos engineering with the Simian Army, regional evacuation. A generic round moves on after the happy path. This one keeps poking at what breaks. So get there first. Name the circuit breaker and the graceful fallback. Talk active-active regions and evacuation. Frame chaos testing as how you know the fallbacks fire. Degrade, don't fail, and be able to say exactly how.

The handling contention lesson and the api gateways lesson cover the gateway and isolation patterns underneath.

What is expected at each level

That is a lot of surface area, and the design round carries real weight at Netflix, often decided as a clean pass or fail. The ladder runs on E-levels now, and most candidates interview at E5, the Senior baseline. How much of the above you need to land scales with the level you are targeting.

E5 (Senior, the baseline)

Breadth, then real depth, roughly 60/40, since E5 is the level most loops are calibrated to. Get to a working end-to-end design, and make the control-plane and data-plane split yourself: AWS thinks, Open Connect delivers. You should raise the read-versus-write skew and reach a Great tier somewhere on your own, with a clear account of the tradeoffs. The Open Connect fill strategy or client-driven ABR is the most natural place to do it. Defend your database choices: why a relational catalog and a write-available store for resume state. The bar: a near-optimal design where you found the bottlenecks yourself and treated availability as a first-class requirement rather than an afterthought.

E6 (Staff)

Depth across several components and a widening scope, roughly 40/60. You are expected to drive the resilience and multi-region story without being led there. That means active-active regions, regional evacuation, circuit breakers and graceful degradation, and how the system behaves when a release spikes traffic tenfold or a region browns out. Expect to reason about cost at this scale, treating the egress bill and the encode matrix as dials you can turn. And expect to explain proactive fill and steering as a coherent strategy rather than a list of features. The bar: you lead the conversation, the interviewer redirects rather than rescues, and the failure modes are where you choose to spend your time.