System Design of YouTube

Welcome back to our exploration of system design! In this installment, we delve into the intricacies of designing a system akin to YouTube or any content uploading platform.

In our previous piece, we discussed about the system design of Netflix. If you missed it, catch up here.

YouTube distinguishes itself by offering free video access and enabling user uploads.

Our focus revolves around the core functionalities:

• Video Watching: Open access to watch a plethora of videos.
• Video Uploading: Empowering users to contribute content.
• Video Search: Seamless video search functionality.
• User Engagement: Interactions such as comments, likes, and subscriptions.
• Channel Creation: Allowing users to create personalized content hubs.
• Bot Management: Handling automated processes within the platform.

Here are the non-functional requirements:

• Reliability: Ensuring consistent and dependable service.
• Scalability: Accommodating growing user base and content.
• High Availability: Minimal downtime for uninterrupted usage.
• Consistency Trade-offs: Prioritizing immediate access to new content over immediate consistency.
• Low Latency: Swift response times for user interactions.

For a structured analysis, we’ll break down YouTube’s primary functionalities into two main components: Video Uploading and Video Watching.

High Level System Design of YouTube:

Uploading the Video:

1. User will upload the video, request will first go to Load balancer considering that very high number of video’s are being uploaded each second, now Load balancer will forward the request to backend Application Server.
2. Uploading the file is not that simple considering that internet connectivity may interrupt the connection in between uploading process. So we are going to store the raw file in the object store. Object store can easily handle large files or media files video. Example of Object store could be AWS S3 it gives us replication as well, Google Drive
3. Now, along with Video we have to store the metadata of video – title, description, who uploaded, tags, user details and profile picture of users. For that we are going to use NoSQL (MongoDB) as it store the details in JSON format with collection of document.
4. Now, same as Netflix we will also use encoding/Transcoding in YouTube to convert the files to multiple format and resolution. YouTube will asynchronously encode the video. They may take some time depending on size of video.
5. After encoding the video, we will store the encoded video into object store.

Watching the video:

1. We will be using CDN servers and caching along with object store and NoSQL DB to minimize the latency and improve the performance.
2. CDN will get the video directly from the encoded object store and metadata from caching server.
3. We need to send the small chucks of videos to the user for the portion that user is actually watching.
4. Now the most important things which protocol we will be using for watching the video. We know that UDP is widely use protocol for live streaming as you don’t prefer to go back but for video that are already stored you would like to see the entire content without missing any bytes. So that makes TCP better choice over UDP in this scenario. Also, TCP can provide the reliability that what we need to achieve non functional requirements.

Thank you for reading. We hope this gives you a good understanding. Explore our Technology News blogs for more news related to the Technology front. AdvanceDataScience.Com has the latest in what matters in technology daily.