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:


  • List the key non-functional requirements (e.g. latency, scalability, reliability, etc.)...


API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...


### Tweet


This API creates a new tweet object for the user, including time stamp, user ID, content (text/image/video etc.) it is how our database get the tweet through the server


### Follow


This API adds the followed user id into the user's following list in the database, we will do some further processing later


### Like


This API does 2 things:

  • Add the post ID into the user's liked posts list
  • Add the user ID into the post's liked user list


UI will update based on our database records and user can press the like button again to cancel the like, then the record will be deleted from both lists (user and post)


### Pull followed users tweets


This API will be called automatically when the user opens the app, the server will go through the followed list and get the followed user IDs, but there's one step before actually go to the home feed, the filter or order tweets API will be called


### Filter or order tweets for home feed display


This API decides how followed user's tweets will be feed to home, the logic will pull the user likes, sort, filter and re-order the followed user tweets by some algorithm and likely using LLM reinforced sorting


High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.


From my diagram


  C[client]

  B{server}

  D[Database]


  T[Tweet API]

  F[Follow API]

  L[Like API]

  D[Display tweets API]

  S[Show top K popular tweets]


  P[tweets database]

  U[user database]


### `Tweet API`


Will save the tweet's content into the `tweets database`.


### `Like API`


Will save the like information into both user and tweets databases, so the tweet object knows who like it, and the user object knows what tweets the user liked. The like can be canceled if the user press the like button again.


### `Follow API`


When user click the follow button `Follow API` is called and the `user database` is updated, so user objects will save who followed who.


### `Display tweets API`


The `Display tweets API` will be called by default when user is refreshing the app, it pulls from `user database` to find what users it followed and then pull from `tweets database` to get a list of tweets to feed into home.


### `Show top K popular tweets`


The `Show top K popular tweets` will be called if the app needs to show a filtered and ordered tweets list based on who the user is following and what tweets the user liked, it pulls from both `user database` and `tweets database`, using some sorting algorithm and LLM reinforced weight calculation to get the final tweets feed list to show to the user.





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.


### User object


The user object should have beyond basic information (ID, name, email etc.), liked tweets list (save tweet ID) and followed user list (save user ID) as foreign keys.


### Tweet object


The tweet object should have beyond basic information (ID, timestamp etc.), a list of users who liked it (save user ID).


### Show top K logic


When the top K API is called, it should check the user liked tweets list (from the user object) and get some tags or categories based on it. Then it should go through the followed users and rank the most interested tweets and feed that into the user's home feed, the pulling will stop after the feed list reached some certain amount, only pull more if the user keeps scrolling and finished reading all of them, we can all ML models for the exact number of tweets to feed in the first time based on each user's habits and screen time etc.


I didn't let the API to pull all followed user's tweets and then filter/reorder to reduce the workload, try to design the logic to only operate what is actually needed for each user.