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.

Not shown in the diagram are standard load balancers.

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

The user database and tweet like database are designed for scale, using a simple NoSQL approach.

tweet(), follow(), and like() should all be trivial and easily scaled.

get_top_tweets_from_followed(user) is a bit more complicated, which is why I added a "smaller list of user's recent tweets" in the user database. That smaller list should make it possible to process all the relevant recent tweets even if a user has hundreds or thousands of followers.

The global top tweets are a more complicated calculation, but only a finite number of recent tweets really need to be considered, which is why we can fit that into a relational DB. We also have caching there which will speed up reads, and provide availability in the face of a single point of failure in the DB.