Requirements

Functional requirements

• Users can create and publish tweets.
• Users can follow and unfollow other users.
• Users can view a home timeline made up of tweets from accounts they follow.
• Users can favorite tweets.
• System supports user profile and follow graph management.
• System stores and retrieves tweets efficiently at very large scale.

Non-Functional Requirements ⚙️

• Performance and scalability: The system should support 100M to 1B users, handle roughly 100K to 1M QPS, and keep tweet posting and timeline loading fast.
• Reliability, availability, and consistency: The platform should remain highly available during normal and peak traffic, with reliable tweet delivery and acceptable consistency between writes and timeline visibility.
• Security: The system should protect user data, enforce privacy and access controls, and support regulatory compliance and moderation-related controls.
• Usability and maintainability: The product should feel responsive and simple for end users, while the backend should be easy to operate, extend, and maintain over time.
• These non-functional requirements will drive architecture choices.

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...

1. POST /tweet

Purpose: create a new tweet

Input

• user_id
• content

Explanation

• Used when a user posts a tweet
• Triggers storage + fan-out to followers’ timelines

2. POST /follow

Purpose: follow a user

Input

• follower_id
• followee_id

Explanation

• Updates social graph
• Affects future timeline generation

3. POST /unfollow

Purpose: remove follow relationship

Input

• follower_id
• followee_id

Explanation

• Removes content source from timeline

4. POST /favorite

Purpose: like a tweet

Input

• user_id
• tweet_id

Explanation

• Records engagement
• May update counters asynchronously

Read path

1. GET /timeline

Purpose: fetch user’s home feed

Input

• user_id
• pagination_cursor

Explanation

• Returns list of tweets from followed users
• Most critical, high-frequency API

2. GET /tweet/{id}

Purpose: fetch a single tweet

Explanation

• Used when opening tweet detail

3. GET /user/{id}/tweets

Purpose: fetch tweets of a user

Explanation

• Used for profile view

user action → API → process → store → fan-out → read from timeline → respond

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

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.