This course immerses the learner into the design of systems and makes them ready for any new design problems.

sys-design.tar.gz

basic

This course provides an alternate perspective to system design where we learn about building blocs first and then use them to build bigger, more capable systems.

Copy-System Design-The Missing Pieces

# High-level design

**Interviewer:** How do you think the components are related to each other.

**Candidate:** The high-level design shows how the various components will be interconnected to support the functional and non-functional requirements.

**Interviewer:** How does this work?

**Candidate:** The workflow for the abstract design is provided below:

1. The user uploads a video to the server.
2. The server stores the metadata and the accompanying user data to the database and, at the same time, hands over the video to the encoder for encoding.
3. The encoder along with the transcoder, compresses the video and transforms it into multiple qualities (like 2160p, 1440p, 1080p, etc.)  for streaming. 
4. The videos are stored on the server's file system (similar to GFS or S3) as well as forwarded to the CDN.
5. The CDN, because of its vicinity to the user, lets the user stream the video with low latency. However, CDN is not the only infrastructure for serving videos to the end-user. Let me get back to that in the detailed design.

**Candidate:** There are a number of reasons why it is a good idea to introduce a server in between the encoder and the client:
- The client can be malicious and abuse the encoder.
- The uploaded video may be a duplicate the server could filter out.
- Encoders will be available on a private IP address within Youtube's network and not available for public access.


Candidate: There are a number of reasons why it is a good idea to introduce a server in between the encoder and the client:
<ul>
<li>The client can be malicious and abuse the encoder.</li>
<li>The uploaded video may be a duplicate the server could filter out.</li>
<li>Encoders will be available on a private IP address within Youtube’s network and not available for public access.</li>
</ul>

**Interviewer:** Why don't we upload the video directly to the Encoder instead of the server? Isn't the current strategy introducing an additional delay?

Interviewer: Why don’t we upload the video directly to the Encoder instead of the server? Isn’t the current strategy introducing an additional delay?

Interview cross-question

Interview cross-question

# API design

**Interviewer:** That's a start. At this point, it will be a good idea to know the design of functionality in the form of an API outline.

**Candidate:** Sure, a good idea to start designing APIs is to translate our feature set into technical specifications. In this case, the REST APIs can be used for simplicity and speed purposes. Our API design section will help us understand how the client will request services from the backend application of Youtube. Let's develop APIs for each of the following features:
- Upload video
- Stream video
- Search video
- Comment video
- Like/dislike video



## Upload video

The POST method can upload a video to the  `/uploadVideo` API:

```
uploadVideo(user_id, video_file, category_id, title, description, tags, default_language, privacy_settings)
```
I would like to explain the parameters here:

- **user_id:** is the user that is uploading the video.
- **video_file:** is the video file that the user wants to upload.

>The video file is broken down into smaller packets and uploaded to the server in order. In case of failures, Youtube can store data for a limited time and resume the upload if the user retries.

- **privacy_settings:** A video may be a public asset or private to the uploader.

**Interviewer:** Other parameters are quite basic so let's move towards the streaming API.

## Stream video
The GET method is best suited for the `/streamVideo` API in the following way:

```
streamVideo(user_id, video_id, screen_resolution, user_bitrate, device_chipset)
```
Some new things introduced in this case are:
- **screen_resolution:** the server can best optimize the video if the user's screen resolution is known.
- **user_bitrate:** the transmission capacity of the user is required to understand which quality of video chunks should be transferred to the client/user.
>The server will store different qualities of the same video in its storage and serve users based on their transmission rate.
- **device_chipset:** many Youtube users watch content over handheld devices which makes it important to know the handling capabilities of these devices to better serve the users.

## Search videos
The `/searchVideo` API will have the following usage:

```
searchVideo(user_id, search_string, length, quality, upload_date)
```
- **search_string:** is the string used for searching videos by their title.

All other attributes can be optional like:
- **length:** to filter videos based on their length in terms of time.
- **quality:** to filter videos based on the resolution like 2048p, 1440p, 1080p, etc.
- **upload_date:** to filter videos based on their date of uploading to the Youtube platform.

## Like/Dislike video
The like/dislike API is fairly simple:
```
likeDislike(user_id, video_id, like)
```
We can use the same API for like/dislike functionality. Depending on what is passed as a parameter to the `like` field, we can update the database accordingly. i.e., `0` for like and a `1` for dislike.

## Comment video
Much like the like/dislike API, we only have to provide the comment string to the API:

```
commentVideo(user_id, video_id, comment_text)
```

# Database schema

**Candidate:** Each of the above features in the API design requires support from the database. i.e., we will need to store the above details in our database schema to provide services to the API gateway.



Copy-Design

High-level design

API design