Netflix or YouTube Design

A video streaming service, such as Netflix or YouTube, is a platform where content creators can upload videos and viewers can search and play videos. Additionally, it’s also able to record video statistics, such as the number of views, number of likes/dislikes, number of minutes watched, etc.

While users pay a monthly subscription fee to enjoy the services of Netflix, YouTube is an advertisement-based service that users enjoy free of cost. Nevertheless, both are video streaming services with similar design basics. Let’s see how a basic video streaming service is designed.

System Requirements

YouTube and Netflix are among the biggest video streaming services on the planet. Their architecture has several components to enhance customer experience. AI-based recommendation systems, billing, popular videos and watch later are all part of such a service, but we will focus on the core features.

Core Features

Our design for a video streaming service will support the following features:

1. Content creators can upload videos.
2. Viewers can watch videos on different devices (mobile, TV, etc.).
3. Users can search videos by their titles.
4. Users can like/dislike or comment on videos.
5. The system can store likes, dislikes and number of views to display these stats to the users.

Goals Of The System

1. There should be no buffering so the viewers can have a real-time experience when watching videos.
2. The system should have low latency and high availability. Consistency is of secondary importance in this case, since it’s acceptable if a newly uploaded video is not available to a user for a while.
3. Video storage should be reliable. Uploaded videos should not be lost.
4. The system should be able to scale with the increasing number of users.

How Much Capacity Should The System Support

Since the system is expected to handle a heavy traffic on a daily basis, a single server cannot support the volume of data. The system will be served by a cluster of servers. Even if one server goes down, no performance issues should be perceived at the client end.

Uploading Video

Our system will be read-heavy. We’ll allocate resources in a way that can retrieve and play videos quickly for the users to enjoy a real-time experience. For each new video upload, there may be 100 views. With this assumption, the read : write ratio is 100:1.

As soon as a new video is uploaded by a client, it’s routed by the load balancer to the upload service. The upload service is simply a microservice for the system that handles uploading videos.

Video Storage

The upload service stores the video in a distributed file storage, such as Amazon S3, HDFS, or Gloster FS. All the video metadata information, such as likes, dislikes, views, size, description and uploader will be stored in the metadata database. It will also carry the file path for the stored video.

How To Onboard A Video

The primary function of YouTube is to onboard a movie or a video. There are several challenges that a video streaming service caters before making a video available to its users.

Storing In Chunks

Instead of being stored as a single large file, each uploaded video will be stored in several chunks. This is necessary because a content creator can upload a large video. Processing or streaming a single heavy file can be time-consuming. When the video is stored and available to the viewer in chunks, the viewer will not need to download the entire video before playing it. It will request the first chunk from the server, and while that chunk is playing, the client requests for the next chunk so there’s minimum lag between the chunks and the user can have a seamless experience while watching the video.

Consider the splitting of videos as an independent microservice handled by the server, video splitter. It will divide the video into smaller chunks and put them in the processing queue. As they are de-queued, the chunks will be encoded.

Processing Queue

A processing queue is needed because there are several chunks for each video and Netflix will use several parallel workers to process them. This is made easier by pushing them into the queue. The workers (or the encoders which we will discuss next) will pick up the tasks from the processing queue, encode them into different formats and store them in the distributed file storage.

Video Encoding

An important step is to convert and store the video chunks into different formats, so different viewers can view it in the format that best suits their device and internet connection. Viewers may be watching the video through their laptop, phone, TV or some other device. Different devices have different formats that work best for them.

Similarly, different viewers may be connected to the internet through different bandwidths. Depending on the speed of their internet connection or bandwidth, some viewers may be able to stream high resolution videos easily, while those with a lower bandwidth will be able to stream low quality videos much more easily.

The original video is a high definition format that can have a size in terabytes. Netflix supports several devices and different network speeds. To make this possible, the system generates and stores over 1200 formats for each movie or show.

You will need to convert each video into different formats (mp4, avi, flv, etc), and different resolutions for each format (e.g. 1080p, 480p, 240p etc). If you have i number of formats to support and j number of resolutions, the system will generate i*j number of videos for each video uploaded to the platform.

For each of the video chunks, A, B, C, and so on, the video encoder will first convert them to, say, .mp4.1080p to store the first set of video chunks for the video. For the same video, another set of video chunks will be generated in .mp4.480p format and so on. The task for this microservice will complete once the sets for all the supported formats are generated.

An entry for each of these sets of chunks will be made into the metadata database and a path will be provided for the distributed storage where the actual files are saved.

Once the video splitting and encoding is complete, the processing of the video file is complete. The client who uploaded the video will be notified and the video will be available on the platform for sharing and viewing.

Open Connect For Improved User Experience

When you request for Netflix.com on your browser, you are actually asking the ISP (Internet Service Provider) to connect you to the Netflix server. The ISP contacts the Netflix IP address for you and returns you the response. However, these servers are concentrated in the US, so for the audience in a far-off country such as Tokyo, there will be a lot of delay in sending and receiving signals. Delays are even more of a problem with videos since a large amount of data needs to reach the viewer and if it’s slow, the streaming will be slow and the user experience will be poor.

Netflix uses an intelligent solution to overcome the problem. It is called Open Connect (OC). Open Connect is Netflix’s customized CDN (Content Delivery Network). CDN is a network of distributed servers and their data centers to cache web content and deliver it quickly to the users by decreasing the physical distance between the user and the content.

Netflix’s Open Connect has partnered with many ISPs across the globe to cache popular Netflix videos so that they may be delivered to the nearby viewers locally, eliminating the need for connection with Netflix’s US-based servers. The Netflix videos are available in the data centers of local ISPs through Open Connect.

How Does A Newly Uploaded Video Reach The Viewer

So once the video is processed (split and encoded) and ready for viewing, it is stored in Amazon S3. It is also pushed to all the Open Connect servers in the world. If a new video is uploaded on Netflix and is to be made available to Australian audiences, it will need to reach the continent via undersea cables.

Instead of directing all the Netflix traffic through this expensive route, Netflix copies the video file (denoted by V in the diagram above) from US-based storage to a storage location in Australia once during off-peak hours. Once the video has reached the continent, it’s copied to all the Open Connect servers present in the ISP networks.

When the viewer presses the play button, the video is streamed from the nearest Open Connect Appliance (OCA) installed at the local ISP and displayed on the viewer’s device.

Load Balancing

Since there are several requests (uploading, search, and viewing requests) coming in every second, a single application server cannot have the capacity to serve all the requests. Since multiple servers are involved, there needs to be a load balancer in place that can redirect requests to suitable servers and efficiently balance load among the servers.

Netflix uses consistent hashing to balance loads among servers since it can effectively manage any failure of servers and incorporate the addition of new servers. Since each video has a different popularity, it may result in an uneven load on the physical servers that handle these videos. To resolve this issue, we can use dynamic HTTP redirections that enables a busy server to redirect a new request to an available server.

YouTube/Netflix Architecture — System Design Diagram

Now that we have discussed the individual components, let’s put them all together to create a complete system, as shown in the system design diagram above.

There are three basic types of requests that can be made to a video streaming application:

• Upload (write)
• Search (read)
• View (read)

Each of these is handled by an independent cluster of servers, keeping in mind that read requests (search and view) will be several times greater in number than write (upload) requests. Since it’s a read-heavy application, you will need to allocate more resources (servers) to serve read requests than uploads.

Each request from a client reaches the load balancer, from where it is redirected to the appropriate microservice.

• Upload Service

An upload request is served by the upload service that processes the video, uploads it to Open Connect servers and makes it available to all the users.

• Search Service

Search request is forwarded by the load balancer to the search microservice and onwards to Netflix’s Elastic search. The response of the Elastic search is returned to the client. Elastic search is a highly scalable full-text open-source search engine that handles searching for millions of videos for Netflix. Netflix also relies on Elastic search for analyzing customer services operations.

• View Service

Most of the view requests will not be directed to the load balancer and Netflix’s servers. Instead, they’ll reach the local ISPs and will be served from the nearest Open Connect server directly. If the requested video isn’t available, however, it will be forwarded to the load balancer and the view microservice. From there, the video is searched in the metadata database and fetched from the path stored in the metadata and sent to the client. Of course, this approach involves delays, which is why any view request is almost always served via Open Connect.