System requirements

Functional:

• able to upload/stream a video
• able to watch/download a video
• Users can like, dislike, comments.

Non-Functional:

• Low buffering
• Scale indefinitely
• Process large video file.
• Copyright acts

Capacity estimation

• 1 Million uploads per day
• 200 Million video watching
• Maximum video file of 100 GB.
• Multiple level of transcoding requires more storage.

API design

• POST /video { video, metadata} - multipart upload
• GET /video/videoId - multipart download
• POST /video/reaction {videoId, reactionId, action(+1 or -1)
• POST /video/comment { videoId, comments}

Database design

Video table :

• Video id
• User Id
• Title
• size
• likes count
• comments count
• Video storage URL

comments:

• video id
• User id
• comments

User:

• user Id
• Email

High-level design

The client will be communicate via API gateway.

It need supports 100M user prepay, need an load balancer and horizontally scalable video service.

1. Video storage on Cloud:
   1. Send the videos in chunks and store in cloud like s3, azure blob
   2. Again take the video from s3 and use transcoder to diversify in multiple levels like 240P .... 4K
   3. Save it back to S3 and store chunk URLs in video table.
   4. The size of each chunk should be less than 2 MB to downloadable so that the user cannot see any buffering.
   5. The chunked videos can cached in CDN for quick accessibility.
2. Database:

a. The video db can be a dynamodb in AWS, the videoId as sort key and channel/user(uploaderid) as partition key.

b. Dynamodb is scalable horizontally

c. we can implement a search on title by adding GSI. Elastic search for title search.

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

1. Video storage on Cloud:
   1. Send the videos in chunks and store in cloud like s3, azure blob
   2. Again take the video from s3 and use transcoder to diversify in multiple levels like 240P .... 4K
   3. Save it back to S3 and store chunk URLs in video table.
   4. The size of each chunk should be less than 2 MB to downloadable so that the user cannot see any buffering.
   5. The chunked videos can cached in CDN for quick accessibility.
2. Database:

a. The video db can be a dynamodb in AWS, the videoId as sort key and channel/user(uploaderid) as partition key.

b. Dynamodb is scalable horizontally

c. we can implement a search on title by adding GSI. Elastic search for title search.

Trade offs/Tech choices

• This application is deployed across regions so there is no issues in certain region users get some delays after video is shown up their country. Availability > consistency.
• Since the video is going through multiple transforming layers we can feel some latency in live streams

Failure scenarios/bottlenecks

• We can have s3 replication for bottlenecks and unavailability
• the video service can spin up/down based on users count.
• If all goes down we can stream from CDN for some time.
• Routing to next available nearest region in case of server down.

Future improvements

• Can we monetization and Ad support.
• Can implement collaborative video streaming.
• Miniature videos.