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 (eg low latency, scalability, reliability, etc.)...

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 - tweet:

GET /tweet/v1/tid

POST /tweet/v1/

Delete /tweet/v1/tid

Tweet - Like:

GET /tweet/v1/tid/like

POST /tweet/v1/tid/like

User:

GET /user/v1/uid

POST /user/v1

PATCH /user/v1/uid

Follower:

GET /follower/v1/uid

ADD /follower/v1/uid

high-level Workflow:

Client

-> API Gateway

-> Auth Service

-> Timeline Service

-> Cache

-> Tweet Cache / Tweet DB

-> Ranking Service

Scalability

• Use CDN in front of LB to serve static files
• Timeline Service would scale up/down based on Kafka queue
• MongoDB sharded with tweetid
• Use Cache to cache hot tweet

Database Design

Tweet Table:

UID int, primary key

TID int

Timeline date, index

description String

Like int

User Table:

UID int, primary key

email var, index

Followers List

Following List

Detailed Component Design

Gateway/Load balancer: Responsible for auth, and direct request to the specific server.

Tweet Server(Web Server): Work with Tweet and Like API, when received a Tweet, it push to the queue(Kafka) and wait for Tweet Scanner to process.

Tweet Scanner(Serveless/Lambda): process the Tweet and store the result into Mongo DB.

DB:

Store the Tweet and User data.

Feed Server:

Process the feed if cache is not hit.