Twitter Design clone

High-level design

Let’s begin with the high-level design of our Twitter system. We will initially highlight and discuss the main components of the design briefly. Later on, we will also deep dive into a few components in this chapter.

• Users post Tweets delivered to the server through the load balancer. Then, it stores in the persistent storage.

• DNS provides the specified IP address to the end-user to start communication with the requested network.

• CDN is situated near the users to provide requested data with low latency. When users search for a specified term or tag, the system first searches in the CDN proxy servers containing the most frequently requested content.

• Load balancer chooses the operational application server based on traffic load on the available servers and the user requests.

• Storage system represents the various types of storage (SQL-based and NoSQL-based) in the above illustration. We will discuss significant storage systems later in this chapter.

• Application server is the one that provides various services and manages different network components.

We have detailed chapters on DNS, CDN, load balancer, and specified storage systems. Here, we will discuss other components in-depth and the specified type of components that we did not discuss in their relevant chapters.

API design

This section will focus on designing various APIs regarding the functionalities we are providing. We will learn how users request various services through APIs. We will only concentrate on the significant parameters of the APIs that are relevant to our design. Although the front-end server can call another API or add more parameters in the API received from the end-users to fulfill the given request, we will consider all relevant arguments specified for the particular request in a single API. Let’s develop APIs for each of the following features:

• Post Tweet
• Like/dislike Tweet
• Reply to Tweet
• Search Tweet
• View user/home timeline

Post Tweet

The POST method is used to send the Tweet to the server from the user through the /postTweet API.

postTweet(user_id, access_type, tweet_type, content, tweet_length, media_fields, list_of_followers, post_time, tweet_location, list_of_used_hashtags, list_of_tagged_people)

Let’s discuss a few of the parameters:

• user_id indicates the user’s unique id who posted the Tweet.

• access_type tells Tweet is protected (only visible to followers) or public.

• tweet_type indicates the Tweet is text-based, video-clip based, image(s)-based, or consists of a combination of different types.

• content specify the tweet’s actual content (text).

• tweet_length represents the text length in the Tweet, in the case of video, the size of a video, and duration.

• media_fields specify the type of media delivered in each returned Tweet like image, video, GIF, etc.

• list_of_followers is the list of followers who posted a tweet on Twitter.

The rest of the metrics are self-explanatory.

Twitter uses the Snowflake service to generate unique ids for Tweets. We have a detailed chapter (Sequencer) that explains this service.

Like/dislike Tweet

The \likeTweet API is used when users like public Tweets.

likeTweet(user_id, tweet_id, tweeted_user_id, user_location)

• user_id indicates the user’s unique id who liked the Tweet.

• tweet_id indicates the Tweet’s unique id.

• tweeted_user_id is a unique id who posted the Tweet.

• user_location denotes the location of the user who liked the Tweet.

The above parameters are also used in the \dislikeTweet API when users dislike others’ Tweets.

Reply to Tweet

The \replyTweet API is used when users reply to public Tweets.

replyTweet(user_id, tweet_id, tweeted_user_id, reply_type, reply_length, ,list_of_followers)

• list_of_followers specify the list of user followers who replied to someone’s tweet.

The reply_type and reply_length are same as tweet_type and tweet_length respectively.

Search Tweet

When the user searches any keyword in the home timeline, ...