Loading...
Scale:
100 M watched per day
70 M DAU
200 uploads per day
movies
movies metadata
users
There has to be an interface to
search a video
play a movie
upload video for the netflix eployees: POST/video
{
video,
videoMetadata
}
watch video
GET/videos/videoID
-> we get video and videoMetadata
We have to have api gateway that does the authetification. Netflix is based on a lot of microservices and data stream due to its massive scale.
I would divide it into two paths:
upload a new video path. AT netflix we don't generate a lot of content every day. So the write throughput is low. We have also transcoding service that takes initially loaded video and process it to have videos in different quality resolutions.
The second part is reading path, which is massive. In order to minimize latency we use CDN foreach country. So the round trips are as short as possible. The
Kafka for handling events. Diffrent topics for diffrent downstream data consumers. WE may have search consumer. analytics consumer. we may have session service downs tream top. subscriptin topic. The more user the more brokers and partitions we add. It's imporant to mention that the message queue and message streams don't contain videos. They only contain the references to the videos that are located on aws s3.
Videos are streamed in chunks via HTTP TCP protocol to user. We want to guarentee the order or bideo chunks.
The upload is also assured by multipart upload. The writes are guereeted via multipart uploads. We use presigned link to s3 to upload movies to s3.
The robustness and reliability are guarenteed by s3 replication and we have high level of reliability.
for nosql database we'll use the extremely fast datbases like dynamodb that allows to retrive the movie or user infor very quickly.
API gateway cannot have message chunks bigger than 10 MB that why we have to have a good chunking strategy for streaming our videos to the user. WE have chunker service that chunks video into 5-10 s clips stored on s3 to send to the client via https requests.