Problem and Scope
Design a system like Twitter, a social media platform that allows users to post short messages, follow other users, and view a timeline of posts from users they follow.
Start by confirming the core user journey, exclusions, success criteria, and the constraints that materially affect the architecture.
Requirements to Clarify
A strong answer should establish scope before choosing components.
Functional requirements:
- Users should be able to create an account and log in
- Users should be able to create, edit, and delete tweets (short messages)
- Users should be able to follow and unfollow other users
- Users should have a home timeline showing tweets from users they follow
- Users should be able to like, reply, and retweet other users' tweets
- Users should be able to search for tweets based on content or hashtags
- Users should have a profile page showing their tweets and basic information
Non-functional requirements:
- The system should support hundreds of millions of daily active users
- The system should handle a high volume of tweets being created and read
- The system should have high availability (99.99% uptime)
- The system should ensure security and privacy of user data
- Timeline loading and tweet posting should have low latency
- The system should be able to scale horizontally
Scale and Capacity
Use the workload to justify storage, partitioning, caching, and reliability decisions. Clarify or challenge these assumptions rather than treating them as unquestionable facts:
- ~200-300 million daily active users
- ~500 million tweets per day (~6,000 tweets per second)
- Each user follows ~200 accounts on average
- Read to write ratio of approximately 100:1
- Each tweet is limited to 280 characters plus potential media attachments
Architecture Discussion
Walk through the important read and write paths, identify ownership boundaries, and explain how the design behaves when dependencies fail. Cover these areas explicitly:
- Frontend clients (web, mobile apps)
- API gateway and load balancers
- User service (authentication, profiles, social graph)
- Tweet service (create, read, update, delete)
- Timeline service
- Search service
- Media storage service
- Notification service
- Databases and caching layers
- Generating and displaying timelines efficiently
- Handling the fan-out problem for users with millions of followers
- Building a scalable search functionality
- Managing media storage
- Ensuring high availability and low latency at scale
- Implementing caching strategies appropriately
Follow-up Questions
Expect the interviewer to test the consequences of your choices. Practise answering these questions with a concrete decision, its benefit, and its cost:
- How would your timeline service handle users with millions of followers?
- Focus: Assess the candidate's answer to "How would your timeline service handle users with millions of followers" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- Can you explain your approach to data storage for tweets and how it supports the read-heavy workload?
- Focus: Assess the candidate's answer to "Can you explain your approach to data storage for tweets and how it supports the read-heavy workload" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What caching strategies would you implement to reduce database load?
- Focus: Assess the candidate's answer to "What caching strategies would you implement to reduce database load" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- How would your design handle a viral tweet that suddenly gets millions of interactions?
- Focus: Assess the candidate's answer to "How would your design handle a viral tweet that suddenly gets millions of interactions" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What trade-offs did you consider when designing the search functionality?
- Focus: Assess the candidate's answer to "What trade-offs did you consider when designing the search functionality" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Evaluation Rubric
MockMe evaluates the answer across the following dimensions. A complete answer should connect claims to requirements and explain consequential trade-offs.
- Requirements and scope (15%): Clarifies and prioritizes the required behavior for Users should be able to create an account and log in; Users should be able to create, edit, and delete tweets (short messages); Users should be able to follow and unfollow other users. Establishes the constraints that materially affect Design Twitter, including The system should support hundreds of millions of daily active users; The system should handle a high volume of tweets being created and read. Strong evidence includes Separates the critical path from secondary features and resolves ambiguous requirements before choosing components.
- Architecture and interfaces (20%): Presents coherent ownership boundaries and end-to-end flows covering Frontend clients (web, mobile apps); API gateway and load balancers; User service (authentication, profiles, social graph); Tweet service (create, read, update, delete). Strong evidence includes Defines interfaces and traces important success, retry, and failure paths across the proposed components.
- Data and scaling (25%): Uses workload assumptions such as ~200-300 million daily active users; ~500 million tweets per day (~6,000 tweets per second) to justify capacity and partitioning decisions. Explains the data, state, or model strategy for Search service; Media storage service; Databases and caching layers. Strong evidence includes Quantifies a dominant workload, identifies the first bottleneck, and explains how the design evolves as that workload grows.
- Reliability, correctness, and safety (20%): Explains concrete failure behavior, recovery, and operational safeguards for Ensuring high availability and low latency at scale; The system should have high availability (99.99% uptime); The system should ensure security and privacy of user data. Strong evidence includes States the required correctness or consistency boundary and covers retries, partial failure, observability, and safe degradation.
- Communication and trade-offs (20%): Drives a structured discussion and compares consequential alternatives for Managing media storage; Ensuring high availability and low latency at scale; Implementing caching strategies appropriately. Strong evidence includes Makes assumptions explicit, answers the question asked, and explains both the benefit and cost of major decisions.