Requirements

Functional Requirements:

1. Create and publish tweets.
2. Follow and unfollow other users.
3. View a home timeline/feed of tweets from people they follow.
4. View a user profile timeline.
5. Favorite and unfavorite tweets.

Non-Functional Requirements:

1. Support very high read traffic because timeline reads are much more frequent than writes.
2. Provide low-latency feed reads, ideally under a few hundred milliseconds.
3. Be highly available, especially for posting tweets and reading timelines.
4. Scale to users with very different follower counts, including celebrities with millions of followers.
5. Handle eventual consistency where acceptable, such as small delays before a tweet appears in followers’ feeds.

API Design

1. Create tweet

POST /v1/tweets

2. Follow user

POST /v1/users/{userId}/follow

3. Unfollow user

DELETE /v1/users/{userId}/follow

4. Get home timeline

GET /v1/timeline/home?limit=50&cursor=abc

5. Get user profile timeline

GET /v1/users/{userId}/tweets?limit=50&cursor=abc

6. Favorite tweet

POST /v1/tweets/{tweetId}/favorite

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.

Detailed Component Design

The system uses service-oriented architecture with event-driven fanout.

Tweet creation is synchronous until the tweet is durably stored.

Feed distribution happens asynchronously through a queue and fanout workers.

Home timeline uses a materialized feed for fast reads.

Profile timeline uses assemble-on-read from Tweet Store.

Celebrity users use fanout-on-read to avoid massive write amplification.

Engagement and notification systems are separate from Tweet Service.

The main correctness rule is: tweets should never be lost; feeds, counts, and notifications can be eventually consistent.