Designing Youtube or Netflix

Step 1: Clarify the Requirements

💡 Always clarify requirements at the beginning of the interview. Ask questions until you know the exact scope of the system the interviewer has in mind.

We will design a simpler version of YouTube.

Functional requirements

1. Users can upload videos.
2. Users can share and view videos.
3. Users can search for videos by title.
4. The service records stats for each video, like likes, dislikes, and total views.
5. Users can add and view comments on videos.

Non-functional requirements

1. High reliability. Any video that is uploaded must never be lost.
2. High availability. We accept weaker consistency in exchange. If a user does not see a new video for a short time, that is fine.
3. Low latency on playback. Watching a video should feel real time, with no lag.

Out of scope: video recommendations, most popular videos, channels, subscriptions, watch later, and favorites.

Requirement 2 trades immediate consistency for availability. Step 6 shows exactly where that staleness appears.

Step 2: Estimate the Scale

Ask the interviewer for the size of the user base and the ratio of uploads to views. Assume 1.5 billion total users, of whom 800 million are daily active users. Assume an average user views five videos per day.

800M x 5 / 86,400 seconds       = ~46K video views per second

Assume an upload:view ratio of 1:200. For every video uploaded, 200 videos are viewed.

46K / 200                       = ~230 videos uploaded per second

Storage. Assume 500 hours of video are uploaded every minute. Assume one minute of video needs 50 MB of storage. That figure is high because we store each video in multiple formats.

500 hours x 60 mins x 50MB      = 1,500 GB per minute (25 GB per second)

These estimates ignore video compression and replication, which would change the real numbers.

Bandwidth. 500 hours per minute is 30,000 minutes of video per minute. Assume uploading one minute of video moves about 10 MB over the network.

500 hours x 60 mins x 10MB      = 300 GB per minute (5 GB per second) incoming

Every uploaded byte is sent out again once per view. With a 1:200 ratio, outgoing traffic is 200 times incoming traffic.

5 GB/s x 200                    = 1 TB per second outgoing

Three of these numbers change the design:

• 46K views against 230 uploads per second. The system is read heavy. Every expensive improvement belongs on the read path.
• 25 GB of new video per second. No single machine can hold this. Video storage must be distributed from the start.
• 1 TB per second outgoing. One data center cannot serve this, which is why a CDN appears in step 6.

Step 3: Define the API

💡 Defining the API early forces you to be concrete about what the system actually does, and it usually exposes a requirement nobody has stated yet.

We can expose the service through REST APIs. Three calls cover the core product: upload, search, and stream.

uploadVideo(api_dev_key, video_title, video_description, tags[], category_id, default_language, recording_details, video_contents)

api_dev_key is the API developer key of a registered account. We use it, among other things, to throttle users based on their allocated quota. The next parameters describe the video: a title, an optional description and tags, and a category_id like Film or Song. Then come the default language and the recording location. video_contents is the video stream itself.

Returns: a successful upload returns HTTP 202 (request accepted). Encoding runs later in the background. When it completes, the user gets an email with a link to the video. We can also expose a queryable API that reports the current status of an uploaded video.

searchVideo(api_dev_key, search_query, user_location, maximum_videos_to_return, page_token)

search_query holds the search terms, and user_location is the optional location of the searching user. maximum_videos_to_return caps the results in one request, and page_token names which page of the result set to return.

Returns: a JSON list of the video resources that match the query. Each resource has a video title, a thumbnail, a creation date, and a view count.

streamVideo(api_dev_key, video_id, offset, codec, resolution)

video_id identifies the video. offset is a time in seconds from the beginning of the video. We store the offset on the server. That lets a user pause on one device and continue on another from the same point. The client also sends codec and resolution. A codec is the format used to compress and decompress video. A TV and a phone use different codecs and resolutions, so both values are needed to resume playback across devices.

Returns: a media stream, one video chunk, starting at the given offset.

Step 4: Define the Data Model

The system stores two very different kinds of data. Video files are large binary objects, and they never go into a database. Step 6 shows where they live. Metadata rows are small and structured, and they go into a SQL database.

The entities come directly from the requirements. Users upload videos, and users comment on videos. That gives three tables: Video, Comment, and User. The video files sit in a separate file store, and each Video row points into it.

Video metadata storage (MySQL). Store the following with each video:

• VideoID
• Title
• Description
• Size
• Thumbnail
• Uploader/User
• Total number of likes
• Total number of dislikes
• Total number of views

For each video comment, store:

• CommentID
• VideoID
• UserID
• Comment
• TimeOfCreation

User data storage (MySQL). UserID, name, email, address, age, and registration details.

The schema below shows the three tables, their keys, and the file store the video rows point into:

Video holds one row per video, keyed by VideoID. This is the same ID that streamVideo takes as a parameter. Title, Description, and Size describe the upload, and search by title reads the Title column. Thumbnail points at the video's thumbnail files. Uploader/User holds the UserID of the uploading account, so one user maps to many videos. The row never holds the video file itself. It keeps the file path into the file store.

The last three columns are the totals of likes, dislikes, and views. Requirement 4 asked for exactly these stats. They are the only Video columns that keep changing after the upload. Step 6 places a cache in front of these hot rows.

Comment holds one row per comment, keyed by CommentID. VideoID names the video the comment belongs to, so one video maps to many comments. UserID names the author, and TimeOfCreation lets us show comments in time order. These five fields are the whole record. We store no location with a comment. The user_location in the search API is a request parameter, not a stored field.

User holds one row per account, keyed by UserID. Both other tables point at it: a Video row names its uploader, and a Comment row names its author. This table grows only when someone registers.

Where does each record live? All three tables live in MySQL. The video and thumbnail files live in the separate file store, shown as the cylinder. Step 6 picks object storage for it, with HDFS as the alternative, and then gives thumbnails their own store.

The other two tables grow with traffic. Step 2 estimated 230 video uploads per second, so Video gains about 230 new rows per second. Comment grows with every comment users write. A metadata row is tiny next to the video file it describes. The files take 25 GB of new storage every second, per step 2. Still, the metadata soon outgrows one database server. Step 6 shards it across many machines, by UserID or by VideoID.

Why a SQL database? These rows have fixed fields and clear relationships, like a comment belonging to a video. That is the shape relational databases are built for. A wide-column store only becomes attractive at extreme scale, and step 6 handles scale by sharding instead.

Step 5: Draw the High-Level Design

At a high level, we need the following parts:

1. Processing queue: Each uploaded video is pushed into a processing queue. Videos wait there to be de-queued for encoding, thumbnail generation, and storage. The queue separates the upload itself from that heavy background work.
2. Encoder: Encodes each uploaded video into multiple formats.
3. Thumbnails generator: Creates a few thumbnails for each video.
4. Video and thumbnail storage: Stores the video and thumbnail files in distributed storage.
5. User database: Stores user information, like name, email, and address.
6. Video metadata storage: Stores everything about a video: title, file path in the system, uploading user, total views, likes, and dislikes. It also stores all the video comments.

The diagram below shows how these parts connect.

Step 6: Go Deep

The service is read heavy. The read:write ratio is 200:1, meaning for every video upload there are 200 video views. So we focus on making the system retrieve videos quickly.

Where are the videos stored?

A video file is written once and read many times. After encoding, it is never edited in place. Two families of storage fit that pattern.

Object storage, like Amazon S3, is the standard answer today. An object store keeps files as named blobs and serves them over HTTP. It replicates every object across machines on its own. That replication is what our reliability requirement demands. Object storage also connects naturally to a CDN, which we add later in this step.

A distributed file system, like HDFS or GlusterFS, also works. HDFS is built for batch jobs that scan very large files. It favors total throughput over the latency of one request. It also makes you operate the replication and the name servers yourself. Choose it when the same files must feed heavy analytics jobs. For serving videos to viewers, object storage is the simpler and cheaper choice.

How should we manage read traffic?

Separate the read traffic from the write traffic. We keep multiple copies of each video, so video reads can spread across many servers.

For metadata, use a primary-secondary configuration. Writes go to the primary first and are then applied to all the secondaries. The secondaries serve reads. This adds read capacity, but it also adds staleness. A new video's metadata reaches the primary first. A secondary that has not applied that write yet returns stale results. Here the staleness lasts a few milliseconds, so the user sees the new video after a very short delay. We already accepted this trade in the non-functional requirements.

Where are thumbnails stored?

There will be far more thumbnails than videos. Assume every video has five thumbnails. Two facts decide the storage choice:

1. Thumbnails are small files, say a maximum of 5 KB each.
2. Their read traffic is huge compared to videos. A user watches one video at a time but sees a page with 20 thumbnails of other videos.

First, evaluate storing all the thumbnails on plain disk. With billions of small files, reading them means many seeks to different disk locations. A seek is the physical movement of a disk head to a new position. Many scattered seeks are inefficient and produce higher latencies.

Bigtable is a reasonable choice instead. It combines multiple files into one block on disk. It is also very efficient at reading small amounts of data. Those are exactly our two requirements. Keep hot thumbnails in an in-memory cache as well. Thumbnail files are small, so the cache can hold a large number of them.

Video uploads

Videos can be huge. If the connection drops while uploading, we should support resuming from the same point. The user should never have to restart a large upload from the beginning.

Video encoding

A newly uploaded video is stored first, and a task is added to the processing queue. The encoder de-queues the task and encodes the video into multiple formats. Once all the encoding completes, the uploader is notified. The video then becomes available for viewing and sharing.

The diagram below shows the detailed component design, with all of these parts in place.

Metadata sharding

Millions of new videos arrive every day, and the read load is extremely high. One database server cannot handle both, so we distribute the metadata across many machines. There is more than one way to split it.

Sharding based on UserID. Pass the UserID through a hash function. The result names the server that stores all metadata for that user's videos. To read one user's videos, hash the UserID again and query that one server. Searching by title is harder. We must query every server, and each server returns a set of videos. A centralized server then aggregates and ranks these results before returning them to the user.

This approach has two problems:

1. What if a user becomes popular? The server holding that user receives a large share of the queries. That one server becomes a performance bottleneck, and it slows the whole service.
2. Over time, some users store far more videos than others. Keeping the data evenly distributed becomes difficult.

To recover, we either repartition the data or use consistent hashing to balance the load between servers.

Sharding based on VideoID. The hash function maps each VideoID to a random server, which stores that video's metadata. To find one user's videos, we query all servers, and a centralized server aggregates and ranks the results. This solves the popular-user problem but shifts it to popular videos. A cache in front of the database servers holds hot videos and absorbs most of that load.

Video deduplication

With this many uploaders, the service receives many duplicate videos. Duplicates often differ in aspect ratio or encoding. They may carry overlays or extra borders, or be excerpts from a longer original. Duplication hurts at several levels:

1. Storage: we waste space keeping multiple copies of the same video.
2. Caching: duplicates take cache slots that unique content could use.
3. Network: duplicates increase the data sent to in-network caching systems.
4. Energy: extra storage, weaker caches, and extra traffic all waste energy.

Users see the cost too: duplicate search results, longer video startup times, and interrupted streaming.

Deduplication makes the most sense early, while the user is still uploading. This is called inline deduplication, as opposed to finding duplicates later in post-processing. Deduplicating inline saves the resources a duplicate would consume in encoding, transfer, and storage. As soon as an upload starts, the service runs video matching algorithms, like Block Matching or Phase Correlation. If we already have a copy, we can stop the upload and use the existing copy. Or we can finish the upload and keep the new video if its quality is higher. If the new video is a subpart of an existing video, or the reverse, we divide the video into smaller chunks. Then we upload only the parts that are missing.

Load balancing

Use consistent hashing among the cache servers. It balances the load between them, and it handles a cache server dying. One problem remains. A static hash maps each video to one hostname, but video popularity is very uneven. A popular video sends heavy traffic to its one logical replica. That uneven load then appears on the physical server underneath.

To resolve this, a busy server can redirect a client to a less busy server in the same cache location. We can use dynamic HTTP redirections for this. A redirection is the server telling the client to request the video from a different address.

Redirections have drawbacks. If the server receiving the redirection cannot serve the video either, the client is redirected again. Each redirection is one extra HTTP request, so the video starts playing later. Redirections across tiers, or across data centers, can also send a client to a distant cache location. Higher-tier caches exist in only a small number of locations.

Cache

Introduce a cache for the metadata servers to hold hot database rows. Application servers check a cache like Memcache before querying the database. Least Recently Used (LRU) is a reasonable eviction policy here. Under LRU, we discard the least recently viewed row first. LRU fits because a video's popularity fades as it ages. The rows being read right now stay in memory.

How can we build a more intelligent cache? Apply the 80-20 rule: 20 percent of the daily read volume generates 80 percent of the traffic. In other words, a small set of popular videos receives most of the views. So we can cache 20 percent of the daily read volume of videos and metadata.

Content Delivery Network (CDN)

A CDN is a system of distributed servers that delivers content based on the user's location and the content's origin. The Caching lesson covers CDNs in more detail.

Our service moves popular videos to CDNs:

• CDNs replicate content in many places. A video is more likely to sit near its viewer, and it crosses fewer networks on the way.
• CDN machines use heavy caching and can mostly serve videos out of memory.

Less popular videos, say 1 to 20 views per day, are not cached by CDNs. Our own servers in various data centers serve them.

One property makes all this caching safe. An encoded video file never changes, so a cached copy of it can never become stale. Only the metadata, like view counts, keeps changing. We already accepted small staleness there.

Step 7: Bottlenecks and Failure Points

The interviewer does not expect this design to be limitless. They expect you to know where it ends.

• A database server dies. Use consistent hashing to distribute data among the database servers. It replaces a dead server with minimal data movement, and it spreads the load while doing so.
• A video goes viral. The cache, the CDN, and dynamic HTTP redirections absorb most of the surge. The metadata shard holding that VideoID is still the hottest single point.
• The processing pipeline falls behind. The queue, the encoder, and the thumbnail generator can all be slow or down. New uploads then take longer to appear, but playback keeps working. Watching a video depends only on the stores, the caches, and the CDN. Say this isolation out loud, because it is a strength of the design.
• Stale metadata reads. A secondary can serve rows a few milliseconds old, so a viewer may briefly miss a brand new video. We chose this in step 1, so present it as a choice, not a defect.

Where AI Fits in This Design

After the main design, interviewers often ask one more question: where would AI fit in this system?

For a video platform, the answer sits in the processing pipeline. That pipeline is already asynchronous. An upload enters the queue, the encoder and the thumbnail generator do their work, and the user waits for none of it. An AI step is simply one more consumer of the same queue.

Two fits matter here. The first is automatic captions. A speech-to-text model (one that turns spoken audio into written text) transcribes each new video, and the result is stored with the metadata. The second is moderation. A classifier (a small model that assigns labels) scores frames and audio for content that breaks the rules. It sends what it finds to human review.

Now apply the same judgment the rest of the design uses. Captions must never block publishing. If the caption job fails, the video still goes live, and the captions can be added later. Moderation is the opposite choice: publishing may wait for it, and that is a product decision, not a technical one. Name the cost too. These models are priced by the minute of video processed, so the bill grows with every upload, whether anyone watches it or not.

Playback needs no AI. The storage split, the caches, and the CDN stay exactly as designed.

💡 In the interview: spend your time on storage and the read path. Say early that the system is read heavy, with 200 views for every upload. The moment the interviewer is listening for is the storage split: video files in object storage, metadata in sharded MySQL, thumbnails in Bigtable. Have the object storage versus HDFS trade ready, and the reason an upload returns HTTP 202 instead of finishing inline. The most likely follow-up is a viral video: answer with the cache, the CDN, and dynamic redirections.

Key takeaway: YouTube is a storage and delivery problem under a very uneven load, with 200 views for every upload. Split the data by shape. Large immutable video files go to object storage, or to a distributed file system like HDFS. Small structured metadata goes to sharded MySQL, and tiny hot thumbnails go to Bigtable. Push every upload through a processing queue, so encoding never blocks the user, and return HTTP 202. Serve popular videos from a CDN and hot metadata from an LRU cache, following the 80-20 rule. Deduplicate inline during upload, and use consistent hashing to spread both database and cache load.