System requirements

Functional:

• User can upload video
• User can search for video with text
• User should expect video upload to be available in multiple resolutions
• User should be able to watch a video with a streaming protocol

Non-Functional:

• Latency for search or initial video catalog view should be low like < 250ms
• Data integrity - my upload video should not be someone else's video

Capacity estimation

• Assume 100M DAU
• Peak traffic 3x
• User upload 1 video per day, but browse 10 videos per day (Read heavy
• Read QPS = 10K QPS Write QPS = 1K QPS

API design

Since we have user involved, we want to ensure data integrity, we can have JWT in the header.

POST v1/upload

{

checksum

parts: [{checksum}]

}

GET v1/{video_id}

GET v1/videos?{text} => 200 m3u8 file

Database design

Video File

====

file_id PK

user_id FK

checksum

s3_uri (To directory)

s3_uri (To manifest file)

Part

====

part_id PK

file_id FK

checksum

s3_uri (To specific raw file)

User

====

user_id

High-level design

• We need a Blob storage like AWS S3
• For now we assume client upload to our dedicated blob server via upload API, but we can optimize later.
• Video processing service

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

• Single S3 PUT call can only take up to 5GB. We should break the files up. We can calculate checksum in the client side, for network failure reupload.
• Video processing service should be written with distributed job scheduler, just like Uber Cadence. Simply because we can define workflow and activities. There are some activities that are more resource consuming. Having all video processing workflow in one pod, assuming we are using K8s, but the concept applies to general compute unit, is not fully utilizing resources and could lead to no checkpoint.
• S3 should store, raw videos, processed videos with different resolutions, and a manifest file for different codec for sub m3u8, then lastly the actual ts files for specific codec. In addition, we can have the thumbnail generated as one of the activities in video processing.

Trade offs/Tech choices

• Video streaming protocol - MPEGDASH or HLS. We use HLS for illustration thus the manifest file is m3u8. HLS is more apple device friendly, while MPEGDASH is more generic. Both have adaptive bitrate adjusted to users' network. RTMP is legacy and no longer updated. WebRTC is more meant for medium size like video conferencing so not suitable for our scale.

Failure scenarios/bottlenecks

_Video upload failure_

> In our previous design, we can use the checksum to ensure we dont reupload the uploaded parts.

Future improvements

_Better failure recover on video upload and also less network overhead_

> S3 presign url. We presign the url and allow user to PUT from client side to S3. This is secure because we use sigv4 request signing algo that we include request headers and request body (body is added in v4 compare to v2)

_Better viewing and video catalog experience_

> We can store video with content delivery network (CDN), a pull based CDN like Cloudfront. For Netflix case, we can use a push based CDN like OpenConnect because we know what videos are likely attract lots of traffic by release schedule. The thumbnails can be on CDN.