List functional requirements for the system (Ask the chat bot for hints if stuck.)...
1) User Authentication
2) Feed Display
3) Post Creation
4) Like and comment
5) Real Time Updates
List non-functional requirements for the system...
1) System should be fault tolorent
2) System should be high available
3) System should have low latency
Estimate the scale of the system you are going to design...
Total number of users 2.9 *10^9
monthly active users =1.74 *10^9
Peak qps =1.74* 10^9 / 10^6 =1.74*10^3
Lets assume our application server can handle 100 request
so number of request handle =1.74*10^3/100 17.4 =18
Lets assume each user makes 3 posts in a day and each post has an image of 200 kb
200*1000*1.74*10^9 =2*1.74*10^12= 3.48*10^12
3.48 TB every day
3.48*365= 1.460 PB every year
Define what APIs are expected from the system...
/registers -> This api is used to register the user for the first time
RequestBody
{
name: "Name String"
"email":"[email protected]"
}
ResponseBody
{
code :201
ResponseString "User Successfully Created"
}
in case of Error
ResponseBody
{
code :400
responseBody :"Add corret body"
}
/post
Request Body
{
Photo:"image"
Description:""
CreatedAt:Timestamp
}
Response Body
{
code 201
Post created Successfully
}
In case of Error
Response Body
{
code :400
Error creating the post
}
/likePost
Request Body
{
postId:"123"
}
Response Body
{
code 200
Liked Successfully
}
In case of Error
Response Body
{
code :400
Error creating the post
}
/CommentPost
Request Body
{
postId:"123"
comment:"Comment String"
}
Response Body
{
code 200
Comment Successfull
}
In case of Error
Response Body
{
code :400
Error creating the post
}
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...
As the post data does not require strong consistency we will be sticking with the NOSQL Database like cassandra or mongodb that will provide us
high availabitly and very easy to scale horizontally. We will be storing details in three tables
User
UserId,
UserName,
UserEmail
Post
PostId
PostCreatedAt
This will store the user and post details with userId as the partition key and postCreatedAt as clustering key
Comment Table
PostId
Comment
Commented At
This will store the comments details with commentId as partitionKey and commentedAt clustering key
Like Table
PostId
LikeCount
This will store the comments details with commentId as partitionKey and commentedAt clustering key
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. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
Each User request will be made to the load balancer which will be redirected to web serever for post creation service the call will be made to api gateway api gateway will implement the functionality for rate limiting as rate limiting is not the scope of design so not discussing the algorithms and request content check so bad body cannot be sent to the user which will redirect the call to postService Each image will be uploaded to blob storage lke s3 using the presigned URL and the comment other metadata will be stored in the database for celebrities we can cache the posts and the liked post for last day so they can be easily be serverd from the cache. We can also use kafka to decouple the service so we can easily scale it we can introduce kafka before storing the data in database and in blob storage . For active users their feed is generated every 5 minutes or when the users refreshed the home page For the active users we can user push model where we can have a cron job that will generated the feed every 5 mintues but for non active users we can have the pull model to pull the feeds from the database and build it. For comments and like we will be storing the metadata in cassandra and for celebrity post we will be storing them in cache as it will be easy to retrive.Cassandra is highly available and can be easily scaled and storing in s3 gurantess high availabitly and cross region replications.
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...
Each User request will be made to the load balancer which will be redirected to web serever for post creation service the call will be made to api gateway api gateway will implement the functionality for rate limiting as rate limiting is not the scope of design so not discussing the algorithms and request content check so bad body cannot be sent to the user which will redirect the call to postService Each image will be uploaded to blob storage lke s3 using the presigned URL and the comment other metadata will be stored in the database for celebrities we can cache the posts and the liked post for last day so they can be easily be serverd from the cache. We can also use kafka to decouple the service so we can easily scale it we can introduce kafka before storing the data in database and in blob storage . For active users their feed is generated every 5 minutes or when the users refreshed the home page For the active users we can user push model where we can have a cron job that will generated the feed every 5 mintues but for non active users we can have the pull model to pull the feeds from the database and build it. For comments and like we will be storing the metadata in cassandra and for celebrity post we will be storing them in cache as it will be easy to retrive.Cassandra is highly available and can be easily scaled and storing in s3 gurantess high availabitly and cross region replications.
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...
Each User request will be made to the load balancer which will be redirected to web serever for post creation service the call will be made to api gateway api gateway will implement the functionality for rate limiting as rate limiting is not the scope of design so not discussing the algorithms and request content check so bad body cannot be sent to the user which will redirect the call to postService Each image will be uploaded to blob storage lke s3 using the presigned URL and the comment other metadata will be stored in the database for celebrities we can cache the posts and the liked post for last day so they can be easily be serverd from the cache. We can also use kafka to decouple the service so we can easily scale it we can introduce kafka before storing the data in database and in blob storage . For active users their feed is generated every 5 minutes or when the users refreshed the home page For the active users we can user push model where we can have a cron job that will generated the feed every 5 mintues but for non active users we can have the pull model to pull the feeds from the database and build it. For comments and like we will be storing the metadata in cassandra and for celebrity post we will be storing them in cache as it will be easy to retrive.Cassandra is highly available and can be easily scaled and storing in s3 gurantess high availabitly and cross region replications.
Explain any trade offs you have made and why you made certain tech choices...
1) Cassandra guratees high availability but sufferes for consistnecy
2) User will see the post which he has posted but other will not see it
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?