Loading...
Posting tweets
Open a user page and see their posts.
Possibility to react and answer to a post
Subscription to an account.
Home feed.
Low latency
Availability
Scalability
20 million daily active users = 100 million tweets/day
200 million daily passive users = read-only
1 billion total users
A globally read-heavy structure mainly.
-> fetch posts from a user
Input: user(, page)
Output: posts, ranked by decreasing time
(would recommend paging to avoid fetching too many posts, e.g {posts_per_page = 10, page = 1})
-> fetch subscriptions
Input: user
Output : user_id of the people followed by user
cf diagram.
Client connects to server, which fetches information from the database with the API described above.
SQL
User table
user_id; username; creation_date; nb_followers; nb_posts
Posts table
post_id; author (~user_id); content; nb_likes; parent_post; enclosed
Subscription
account; follower
(there can be several times the same value in each column, but no duplicate rows)
Storing post parent-child relationship as tree in NoSQL
If files enclosed to the post, a link in posts.enclosed column refers to the actual file stored in an AWS S3 bucket.
I don't really see how to store likes per post in a way that's efficient to retrieve
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.