Requirements of Twitter’s Design
Explore the critical functional and non-functional requirements that define the scope of the Twitter System Design. Analyze constraints like scalability, consistency, and latency to inform architectural decisions for a massive, read-heavy platform.
We'll cover the following...
Requirements
We will outline the system’s functional and non-functional requirements below.
Functional requirements
The system must support the following core features:
Post tweets: Users can publish messages containing text and media.
Delete tweets: Users can remove their own content.
Like or dislike: Users can engage with tweets by liking or disliking them.
Reply: Users can reply to public tweets.
Search: Users can search for content using keywords, hashtags, or usernames.
View timelines: Users can view the home timeline (tweets from people they follow) and the user timeline (their own tweet history).
Follow or unfollow: Users can follow or unfollow other accounts.
Retweet: Users can share other users’ public tweets.
Non-functional requirements
Availability: The service must be highly available. As Twitter is often used for time-sensitive communication during emergencies, uptime is critical.
Latency: The system requires low latency to deliver feeds and ensure a smooth user experience. While complex feed generation can run asynchronously, the user’s read path must remain fast.
Scalability: The workload is read-heavy, with an estimated 1:1000 write-to-read ratio. The system must scale computationally to handle high traffic and provide massive media storage capacity.
Reliability: Data durability is essential. The system must ensure that uploaded content is never lost or corrupted.
Consistency: We can accept
eventual consistencyfor the system’s global view. For example, a user in the US East region might see a tweet slightly before a user in the US West. However, the system must provide immediate feedback to the user acting (e.g., a user must see their own like or reply instantly).