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:

• Low latency, especially for non-write actions.
• High availability (more important that consistency)
• Scales to large volume of users, reads, and follows.

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

API Design

• tweet(user, text)
• follow(user, target_user)
• like(user, tweet_id)
• get_home_feed(user) calls
  • get_top_tweets_from_followed(user)
  • get_top_global_tweets(k)

High-Level Design

Using horizontally scaling systems, including NoSQL databases, as shown, all the API calls should be easy to evaluate in real time, except for get_top_global_tweets. That one can be run reads from a small relational DB. The keys for that relational DB are populated offline every few minutes from a job that reads the Tweet like database, but the relational DB gets updated every time a tweet in that DB gets liked."

Writes:

• tweet() will write a tweet to the User database, and then add it to the tweet database. If it fails to get added to the Tweet database, that can be recovered later from the user database.
• follow() writes to the user database, for both users.
• like() gets written to the tweet database. If the tweet isn't found there, we create it from the user database. If the tweet is in the top global tweets, update it there too.

Reads:

• get_top_tweets_from_followed(user) looks up followed users from the user database, and then looks up their recent tweets in the user database.
• get_top_global_tweets reads from the Top global recent tweets.

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

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.