Requirements
Functional Requirements:
- Allow users to tweet messages up to 140 characters.
- Enable users to follow other users.
- Allow users to like tweets from other users.
- Display tweets from followed users in the home feed.
- Show top K popular tweets in the home feed based on likes and followers.
Non-Functional Requirements:
- 99.99% uptime
- low latency when loading tweets
- low latency across the globe
API Design
tweetContent{
PK tweetId:int
username:string
createdAt:datetime
editedAt:datetime
description:string
media:string[]
}
user{
PK userId:int
username:string
email:string
description:string
}
userFollows{
FK follower:int(userId)
FK following:int(userId)
}
statusMsg{
code:number
description:string
}
POST /tweet/create
{
tweetContent
}
-> statusMsg
DELETE /tweet
{
tweetId:int
} -> statusMsg
GET /post/:tweetId -> tweetContent
PATCH /tweet/:tweetId
{
tweetId:int
newTweetContent:tweetContent
}
-> statusMsg
POST /tweet/like
{
tweetId:int
userId:int
} -> statusMsg
GET /timeline/:userid
-> tweetContent[] //customized for the user by follows
GET /popular
-> tweetContent[] //by popularity
POST /follow
{
followerId:int
followingId:int
} -> statusMsg
High-Level Design
There needs to be a frontend client connected to an API controller, which connects to a server with tweet service and user service. Tweet service handles CRUD of tweets DB and user service handles CRUD of users DB, tweet service also handles the algorithm for timeline and popular posts. Both services are connected to the same SQL DB while the tweet medias are uploaded to S3 then store the media keys in tweet db. When user create post the backend service first creates a presigned url from S3 then make sure client upload the media before postContent is stored into SQL. When user requests media files it requests to the CDN of S3 storage.
Detailed Component Design
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.