System requirements

Functional:

• Users can upload images
• Users can follow other users
• User gets timeline feed of latest content from followers
• Content can be viewed on different devices, will need to be transcoded to several formats
• Video will be streamed in chunks
• System is read heavy - more users viewing content than creating/writing content

Non-Functional:

List non-functional requirements for the system...

• Highly available - should be able to access at any time
• High scale, lots of users, some users have millions of followers
• Fault tolerant, recover when needed
• User content is always available

Capacity estimation

Estimate the scale of the system you are going to design...

• 100M users, 50M concurrent users
• 100,000 uploads/day, 100MB / content
• 10M MB / content / day --> 10 TB / day or 4 PB / year
• 100,000/ 24 / 60 / 60 - 1 upload / request / second



API design

Define what APIs are expected from the system...

• /Auth - username, password use 3rd party auth service
• /Upload /:userid- specific to a user, store in blob storage
• /ViewContent/:userid - returns a timeline of content based on recent follower interaction
• /Archive/:userid/:contentid
• /Transcode/:contentid
• /Stream/:contentid
• POST /interaction/:userid
• GET /interactions/:userid
• POST /addfollower/:userid/:followerid
• GET /follower/:followerid

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

Store Content - Blob storage, keep track of path in nosql DB

Content - nosql

• id - hash
• userid - hash
• created - datetime
• path - string

User - sql

• id - hash
• username - string
• password - encrypted text
• bio - string
• follower count
• path to s3 user

Followers - nosql

• id - hash
• userid - hash to user table

Interactions - no sql

• id - hash
• userid - hash to user table
• followerid - hash to follower table
• interaction type - enum string
• created - datetime

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design...

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...

User uploads content to their profile

• User is authenticated
• User is routed to server with capacity
• Raw content is written to content DB
• Raw content is added to the upload queue
• Transcoder picks up content and begins transcoding
• Transcoded coded content is written to the blob storage and path is written to the content table

User wants to view latest Feed

• User is authenticated
• User is routed to server with capacity
• User API queries the Feed API
• Feed API determines the feed by taking the followers with most interactions with the user, looking for the latest content, packaging in to a response
• User API determines the media format to fetch based on the viewing device, makes a call to the DB, uses the path to blob storage to retrieve the content from the feed api response
• Content is ordered based on time and followers with most interactions

User views Reels videos

• User is authenticated
• User is routed to server with capacity
• User API makes request to the Stream API determines videos to show user
• Stream API queues up initial chunks of several videos in the desired media format, let's say 5 seconds a piece
• Stream API returns to the User API the chunks of video and displays in a horizontal media player
• When user selects a video to play the User API makes additional calls to the streaming API to get additional chunks of video as the video is consumed

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Transcoder - how to encode raw content and get several different formats as output

• the outputted content gets stored in the blob storage and the path is written to the content table
• videos are chunked based on max chunk size

Feed API - determines the latest content to deliver to the user display based on the followers the user interacts with the most

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

SQL vs nosql - for some tables sql makes sense based on estimated size and schema, for others like content and interactions the estimate size could grow exponentially so scale and flexibility would be solved with nosql

blob storage for content makes sense because the content contains larger file sizes that can be streamed to the user based on several things like target viewing device and chunk if streaming video

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Could see one user with many followers upload content and followers looking to update latest feed at the same time. In this case the Feed API will be very stressed with the high volume

• solution could be to pre-compute feeds which could be done when user if offline - this way we don't have millions of users making the same call at the same time
• Another solution could be to use a CDN or caching system to determine the most likely followers a user would interact with to cut down on latency

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?

Replicas of DBs, the content and interactions DB would be partitioned well using nosql solutions like cassandra and would also make sense to keep separate DBs for writes and reads with replication system to track of consistency between replicas

• Also would keep DBs in separate regions so user is interacting with services nearest to the them, cutting down on latency

Compaction of old data. Users are most likely to interact with the latest content produced by followers. However, we still need to preserve old content so it is available when user would like to use it. To help cut down on storage costs we could implement a compaction system that determines when content is stale and will compact to a smaller size or keep only lower resolutions of the content rather than high resolution which is larger in size and the cost to store it