Loading system design…
Loading system design...
Design the home timeline (news feed) for a Twitter-like social media platform. When a user opens their home page, they see a feed of tweets from accounts they follow, sorted by recency or relevance. This is one of the most classic system design problems, centred on the fan-out problem: how to efficiently distribute a single tweet to millions of followers' timelines.
| Metric | Value |
|---|---|
| Daily active users (DAU) | 300 million |
| Tweets posted per day | 500 million (~6,000 per second) |
| Average follows per user | 200 accounts |
| Max followers (celebrities) | 50+ million |
| Timeline reads per day | 30 billion (~350,000 per second) |
| Timeline cache per user | 800 tweetIds × 8 bytes = 6.4 KB |
| Total timeline cache (Redis) | 300M × 6.4 KB ≈ 1.9 TB (× 3 replicas ≈ 5.7 TB) |
| Tweet storage per day | 500M × 300B ≈ 150 GB |
Users can post tweets (up to 280 characters) with optional media attachments (images, videos, GIFs)
Users can follow and unfollow other users
Home timeline: users see tweets from all accounts they follow, ordered by recency (reverse chronological)
Timeline should load within 200ms and support infinite scroll with cursor-based pagination
Support retweets (share another user's tweet) and quote tweets (share with commentary)
Users can like, reply to, and bookmark tweets
Timeline can be sorted by relevance (algorithmic ranking) in addition to reverse chronological
Support @mentions and hashtags; tapping them navigates to user profile or topic page
Show trending topics based on tweet volume and velocity within a time window
Near real-time timeline updates: new tweets from followed accounts appear without manual refresh
Non-functional requirements define the system qualities critical to your users. Frame them as 'The system should be able to...' statements. These will guide your deep dives later.
Think about CAP theorem trade-offs, scalability limits, latency targets, durability guarantees, security requirements, fault tolerance, and compliance needs.
Frame NFRs for this specific system. 'Low latency search under 100ms' is far more valuable than just 'low latency'.
Add concrete numbers: 'P99 response time < 500ms', '99.9% availability', '10M DAU'. This drives architectural decisions.
Choose the 3-5 most critical NFRs. Every system should be 'scalable', but what makes THIS system's scaling uniquely challenging?
The complete explanation is included with Career and All Access. Compare it with your approach once you’ve worked through the problem.
Your system-design submission history is available after you sign in.
Sign In