Requirements

Functional Requirements:

• User should be able to create a tweet
• User should have a feed of posts to view
• User can like on a tweet
• User can reply on a tweet, and that should link up with the master tweet

Non-Functional Requirements:

• 100M+ users
• Low latency APIs with 200ms response times
• Highly available with targeted 99% uptime

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

• POST /tweet - create a tweet
• GET /home - get a list of tweets
• GET /profile - get a profile of user
• GET /tweet/:id - get details of a specific tweet
• PATCH /like - Like/Unlike a tweet
• PATCH /follow - Follow/Unfollow a user

High-Level Design

• Use MongoDB to store parts of data - such as users and tweets since they can be sharded.
• Use SQL to store data that needs frequent processing; such as likes and follower data (can use clauses like GROUP, COUNT for faster results)
• Use RabbitMQ for queuing.
• Use Azure Blob Storage/Amazon S3 for storing media along with CDN on top for faster retrievals on basis of geographical location.
• Use Kubernetes for managing pods and scaling up and down servers as per load.
• Use read replicas for DB.

Database Design

Use NoSQL for sharding (high-volume data). Not a lot of logic and relations need to be present in DB, so NoSQL makes more sense

Tweets:

• ID
• TweetContent
• MediaLink
• CreatedBy
• LikesCount
• ParentTweetID

Users

• ID
• UserName
• ProfilePicture
• FollowerCount
• FollowingCount

SQL DB (Fast retrieval):

TweetLikes:

• TweetId
• UserId

UserFollowing:

• FollowerUserId
• FollowingUserId

Detailed Component Design

• FeedViewer- Takes a user's authentication details, plugs it into a recommendation system which then outputs a list of tweets that we can show to the user
• EventPublisher - A generic service that is used for fan-out notifications on the basis of followers and following.
• CDN with short TTL - Viral tweets should be served via CDN instead of each request hitting the server and DB - short TTL so time-sensitive data such as likes of follower counts can be EVENTUALLY CONSISTENT.
• LikeService - liking a tweet will fire 2 events in an async fashion - update the like count in MongoDB and add a row for the like in SQL DB. User doesn't need to wait for these services to respond immediately, so this API is fast by design.
• FollowService - similar to LikeService, 2 separate events fire for SQL and NoSQL writes.