System requirements
Functional:
- User should be able to create a tweet.
- User should be able to track other users tweet.(timeline)
- User should be able to like other tweets.
Non-Functional:
- Availability
- Reliability
- Latency
- Character limit up to 100 chars
- Scalability
- Monitoring and Logging
Capacity estimation
Let's say we have 10M users.
write:read => 1:10
Writes:
1M active users => 1 post per user
1 post => 100 bytes
1M posts => 1M * 100 bytes => 100MB
10 years => 10 * 365 days * 100MB => 400 GB(approx.)
Reads:
1M active users => 10 reads per user
1M * 10 => 10M reads
API design
- /post_tweet/tweet_data: Reponse: tweet posted. http 200 ok
- /get_tweets: response tweets that the user follows
- /like_tweet: tweet liked
Database design
User
- user_id
- dob
- first_name
- last_name
Tweet
- tweet_id
- user_id
- tweet_url
- number_of_likes
High-level design
User will create a post and would connect to the server to create a tweet. the server will store tweet data to s3 and we will store all the details of tweets to the tweets table. the s3 path will be store in tweet url.
Request flows
User will create a post and would connect to the server to create a tweet. the server will store tweet data to s3 and we will store all the details of tweets to the tweets table. the s3 path will be store in tweet url.
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...
Trade offs/Tech choices
Explain any trade offs you have made and why you made certain tech choices...
Failure scenarios/bottlenecks
Try to discuss as many failure scenarios/bottlenecks as possible.
Future improvements
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?