Loading...
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
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.
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.