Design Netflix

Clarify the ask

The interview question is to design Netflix.

A viewer opens the app and picks a title. Playback starts quickly and stays smooth to the end.

Accounts, billing and profiles exist around the edges. Playback is the core the design must protect.

Viewers upload nothing. That one fact separates this design from YouTube, where uploads drive everything.

Estimate the scale

The catalogue holds 15,000 titles.

Each title is pre-encoded into 120 versions. The versions cover different resolutions, bitrates and formats.

15,000 titles × 120 versions = 1,800,000 stored files.

Peak viewing is 50,000,000 streams at the same time. An average stream uses 5 megabits per second.

50,000,000 streams × 5 megabits per second = 250 terabits per second of peak delivery.

Reads dominate this design completely. Writes are rare and planned, because new titles arrive on a release schedule.

What the design must get right

Playback must start fast on a home connection and on a phone. A long wait at the start loses the viewer.

Playback must adapt when the connection slows down. Adaptive bitrate switches the version mid-stream.

A viewer can stop on one device and resume on another. The design stores a viewing position for each profile.

The catalogue must browse well without playing anything. Titles, artwork and descriptions are small data beside the video.

The high-level shape

Small control services handle sign-in, browsing and play requests. They move no video at all.

Video flows from caches placed near viewers. The caches hold the prepared files and serve them directly.

A play request is a short conversation with the control services. It ends with the address of a nearby cache that holds the title.

A known catalogue turns streaming into a preparation problem. Prepare everything early, then deliver it from nearby.

Where the design breaks

Evening peak is the hard hour. Millions of viewers press play within the same few minutes.

A popular release concentrates demand on a few titles. Those titles must sit on many caches before release.

A failed cache at peak pushes its viewers onto neighbours. The neighbours need spare room for that surge.

Encoding prepares the files. Delivery moves them. The seams rank what viewers see.

The catalogue pipeline

A catalogue pipeline is the set of steps that turns one master copy of a title into every playable version. The pipeline runs once per title, long before release.

The pipeline feeds the rest of the design.

A studio delivers one master copy of each title. The master is the best-quality source the design ever receives.

No viewer ever plays the master. Players play renditions, the versions that transcoding produces from the master.

From master to versions

The master lands in blob storage first. A checksum, a small value computed from the file, proves the copy arrived whole.

Transcoding then turns the master into renditions for different screens. A large television and a phone need different resolutions and bitrates.

Formats multiply the count again. Different players accept different file formats for the same picture.

That is how one title becomes 120 versions. Each version is a separate stored file, ready to stream.

What the versions cost

In this design one stored version averages 2 GB. That figure is a stated assumption.

120 versions × 2 GB = 240 GB stored for one title.

The catalogue holds 1,800,000 stored files.

1,800,000 files × 2 GB = 3,600,000 GB of stored video.

3,600,000 GB is 3,600 TB. Storage is a real cost of preparing everything in advance.

Encoding as background work

Encoding is slow work, so it runs as background jobs. A queue holds the titles waiting to be encoded.

Workers take one title at a time from the queue. Each title is split into short pieces, and the pieces encode in parallel.

Parallel pieces turn hours of encoding into a much shorter wait. The finished pieces are joined back into whole versions.

A failed piece retries on its own. Retrying one piece never restarts the whole title.

Each encoding job is idempotent. Running the same piece twice gives the same file, so retries are safe.

Metadata and release

Catalogue metadata lives apart from the video files. Title, artwork, cast and description sit in a database, small beside the video.

Browsing reads only metadata. A viewer can search the whole catalogue without touching a video file.

A title becomes visible only when its versions are ready. Publishing is one deliberate switch, not a gradual leak.

A prepared catalogue stays predictable. Release day changes demand, never the files themselves.

Where encoding breaks

A corrupt master poisons every version made from it. The checksum check at arrival is the guard, and a bad master is sent back.

A job that fails again and again lands in the dead-letter queue. A person inspects it instead of the queue retrying forever.

An urgent release compresses the schedule. Core versions encode first, and the remaining versions follow after release.

The design accepts that split rarely. A title missing some versions still plays, at fewer quality levels.

Delivery at depth

Delivery is the path that carries video from storage to the viewer's screen. At peak it moves 250 terabits per second, so almost all of it must come from caches near viewers.

50,000,000 streams × 5 megabits per second = 250 terabits per second at peak.

No central fleet serves that rate sensibly. The bytes must already sit close to the viewers who will ask for them.

Caches near viewers

Cache servers sit inside or beside the networks that serve homes. A stream then travels a short local path, not across an ocean.

Popular titles are pushed to the caches before the evening peak. A fixed catalogue makes that push a planned job, not a guess.

Rarely watched titles stay in regional storage instead. A cache fetches one on first request and keeps it while demand lasts.

In this worked example one busy cache serves 10,000 streams at the same time.

10,000 streams × 5 megabits per second = 50,000 megabits per second from one cache.

50,000 megabits per second is 50 gigabits per second. One cache is a serious machine, and peak needs very many of them.

Choosing the cache

A play request first reaches a control service. The service answers with the address of a cache that holds the title.

The choice weighs three things. The cache must be near the viewer, hold the title, and have spare capacity.

Steering uses the viewer's network location and live cache load. DNS and load balancers carry the request to the steering service.

If the chosen cache lacks the title, the request moves to the next cache. The viewer sees a slightly slower start, not an error.

Service discovery inside

Service discovery is how one service finds the current healthy addresses of another service. The control services depend on it for every play request.

Each instance registers its address when it starts. Health checks remove instances that stop answering.

Callers ask the discovery service, or hold a list it keeps updated. Either way, callers never hard-code addresses.

Addresses change constantly at this scale. Instances are replaced, scaled up for the evening and scaled down after it.

A stale list sends requests to a dead instance. The caller times out, asks for fresh addresses, and retries against a healthy one.

Adaptive playback

Video travels in short pieces of a few seconds each. The player fetches one piece at a time and keeps a small buffer ahead.

Adaptive bitrate lets the player switch version between pieces. A slowing connection drops to a smaller version before the buffer empties.

Every version of a title is cut into pieces at the same points. Switching versions mid-film stays invisible because the pieces line up.

The many versions from encoding exist for this moment. Preparation is what makes adaptation cheap at playback time.

Where delivery breaks

A failed cache at peak moves its viewers to neighbouring caches. Steering spreads them out instead of flooding the single nearest cache.

If caches miss together, requests fall back to regional storage. That path is slower and dearer, so it is a bridge, not the plan.

Graceful degradation protects the stream itself. A new play can start at a lower quality rather than fail while the system recovers.

A much-anticipated release is pre-positioned days ahead. Release night then looks like any other peak to the caches.

Recommendation seams

A recommendation seam is the place in a design where a ranking service plugs into the product.

A seam is a boundary with a clear contract on each side.

How ranking works is left to a separate design.

Ranking decides which titles a viewer sees first. Playback decides how a chosen title streams, and it never depends on ranking.

Keeping the two apart is the main idea. Ranking can change, fail or be rebuilt without touching delivery.

Where ranking plugs in

The home screen is rows of titles. Ranking fills each row and orders the titles inside it.

Search results pass through the same seam. Matching titles come from the catalogue, and ranking orders the matches for this viewer.

A title page offers similar titles below the description. That list is another answer from the same ranking seam.

Continue watching needs no ranking at all. It reads the viewer's own viewing positions, newest first.

What data flows in

Viewing events flow into the seam as facts. A play, a pause, a finished film and an abandoned one are each recorded.

Events travel on a queue, apart from playback. Losing an event loses a signal, never a stream.

Searches and row clicks are events too. They show what a viewer wanted, including when nothing was chosen.

Events carry the profile, the title and the time. Profiles keep the signals of different viewers in one household apart.

What the seam returns

The request side of the contract is small. It names the profile, the screen being built, and the device in use.

The response side is an ordered list of title identifiers. It carries no video, no artwork and no descriptions.

The app service turns identifiers into a screen using catalogue metadata. Metadata stays owned by the catalogue, not by ranking.

The contract is the whole seam. Either side can change its internals while the contract holds.

Keeping the seam safe

Every ranking call carries a short timeout. A slow answer is treated the same as no answer.

On timeout the app serves a fallback list of popular titles. The screen still fills, and the viewer notices nothing.

The last good response can be cached briefly per profile. A brief outage then shows slightly older rows, not an error.

Ranking never sits on the video path. Pressing play talks to control and caches.

What this design does not decide

How a model ranks titles is a separate design problem. This design names where ranking plugs in, never how it ranks.

That restraint is deliberate. An interview answer that wanders into model internals loses the system it was asked to design.

The seam still earns its place in the design. Rows, search order and similar titles all depend on its contract.

Evaluation

The Netflix trade-offs weigh preparation against storage and closeness against cost. Every choice in this design follows from the fixed catalogue.

Each trade-off is a choice with a price on both sides.

The fixed catalogue tilts most of these choices the same way. Preparation is possible, so this design prepares.

Preparing titles takes encoding everything in advance. The price paid is storage for rarely watched versions.

Serving video takes caches near viewers. The price paid is many cache sites to run.

Viewing positions take eventually consistent copies. The price paid is a resume point that can lag briefly.

Ranking takes a seam with a fallback list. The price paid is rows that go stale during an outage.

Prepare everything, or on demand

Encoding on first request would save storage for the long tail. A title watched once a year would cost almost nothing to keep.

The price is the first viewer's wait. Encoding takes far longer than a viewer will sit looking at a spinner.

This design pre-encodes the whole catalogue and pays the storage. Instant starts for every title are worth more than the saved disks.

The stored catalogue runs to thousands of terabytes. That is the scale of the storage price.

Caches near, or origin central

A central origin would be simpler to run. It would also have to serve 250 terabits per second at peak across long distances.

50,000,000 streams × 5 megabits per second = 250 terabits per second, and distance makes every bit slower and dearer.

Caches near viewers cost sites, hardware and steering complexity. They buy short paths and a peak the origin never sees.

Pushing titles out before peak costs bandwidth in quiet hours. It buys certainty in the loud ones.

Consistency where it matters

Catalogue publishing is kept exact. A title is visible everywhere at once, or not yet visible anywhere.

Viewing positions can lag briefly between regions. A resume point a few seconds behind is a small annoyance, not a broken promise.

Viewing events can arrive late or out of order. They feed ranking signals, where a late event changes little.

The pattern is deliberate. Exactness is spent only where a viewer would notice its absence.

Capacity for the peak hour

The fleet is sized for the evening peak. Much of it idles in the middle of the day.

Undersizing would be cheaper all day and broken every evening. The peak is the product's busiest and most visible hour.

Background work fills some idle hours instead. Encoding and cache pushes run when viewers are few.

The wrap-up

The design in one line. A fixed catalogue is prepared once, pushed near viewers, and streamed from there at peak.

Control stays small and central enough to steer. Video stays local enough to be cheap and fast.

Ranking plugs in at a seam and can fail without stopping a single stream. That separation is the design's quiet strength.

The Netflix estimate at a glance