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:
High availability — if Twitter goes down nobody can tweet or see their feed
Low latency — feed should load in under 100ms
Scalability — needs to handle hundreds of millions of users and massive traffic spikes
Eventual consistency — it's okay if a new tweet takes a few seconds to appear in all followers' feeds
- Durability — tweets and likes can never be lost
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
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
POST /tweets
input: { user_id, content }
output: { tweet_id, created_at }
DELETE /tweets/:tweet_id
input: { user_id }
output: { confirmation }
POST /tweets/:tweet_id/like
input: { user_id }
output: { like_count }
DELETE /tweets/:tweet_id/like
input: { user_id }
output: { like_count }
POST /users/:user_id/follow
input: { follower_id }
output: { confirmation }
DELETE /users/:user_id/follow
input: { follower_id }
output: { confirmation }
GET /feed
input: { user_id, page }
output: { list of tweets from followed users }
GET /feed/trending
input: { limit }
output: { top K tweets by likes and followers }
High-Level Design
Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.
"The system starts with the client hitting the API gateway which handles authentication and rate limiting. The load balancer routes requests to four microservices — tweet service, like service, follow service, and feed service. The tweet service handles creating and deleting tweets, storing content directly in the database since tweets are plain text up to 140 characters. Likes and follows are write-heavy and non-critical so they go through a Kafka queue and are processed asynchronously by a worker server. The feed service is read-heavy — it checks a dedicated feed cache first before hitting the database. A background ranking service runs periodically, computes the top K tweets by likes and follower count, and stores the result in cache so the trending feed is always fast. All writes go to the primary database which replicates to a secondary for redundancy."
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 like service receives high volumes of like events continuously. Writing each like directly to the database would overwhelm it during viral moments, so likes are dropped into a Kafka queue immediately and the user gets an instant response. A worker server consumes from Kafka, batches the like events, and writes them to the database in bulk. This keeps the database load manageable even during massive traffic spikes.
The feed service is the most read-heavy component — every time a user opens Twitter they're loading their feed. The feed for each user is precomputed and stored in Redis cache. When a new tweet is posted the worker server pushes it into the relevant followers' feed caches. This means feed reads are almost always cache hits and never touch the database directly.
The ranking service is a background job that runs every few minutes. It queries the database for tweets with the highest like counts and follower-weighted engagement scores, computes the top K results, and writes them to a dedicated cache. When a user requests the trending feed the display server reads directly from that cache — no real-time computation needed. The tradeoff is trending tweets update every few minutes rather than instantly, which is acceptable for this use case."