Design a News Feed (Twitter / Facebook-style Timeline)
"Design Twitter's home timeline" is the single most common system design interview question, and for good reason: it packs a read-heavy workload, a hard fan-out trade-off, a caching layer with a real sizing question, a social graph that resists sharding, and one famous edge case (celebrities) into a 45-minute conversation. If you can answer it well, you have demonstrated almost every skill the interviewer is grading.
This subject is written as a model answer, following the four-step framework from the System Design Interview Framework subject: (1) clarify requirements, (2) estimate capacity, (3) draw the high-level design, (4) deep-dive the interesting parts. Every step uses explicit numbers so you can reproduce the reasoning under time pressure. Where a topic is taught elsewhere in this track — caching policies (Caching Strategies), queue semantics (Message Queues and Event Streaming), sharding mechanics (Database Replication and Sharding), the CDN and load-balancing tiers — we state the boundary and move on rather than re-teaching it.
Time budget in a real interview: about 5 minutes on requirements, 5 on estimation, 10 on high-level design, 20 on deep dives, 5 for follow-ups. Say the budget out loud; interviewers appreciate a candidate who drives.
Step 1 — Requirements
Functional
- Post: a user publishes a post (text ≤ 280 chars, optional images/video).
- Follow: a user follows / unfollows another user (directed graph, no approval).
- View feed: a user opens the app and sees a list of recent posts from the people they follow, newest first (chronological — ranking is a follow-up), paginated, ~20 per page.
Out of scope unless asked: likes/comments/retweets, notifications, search, DMs, ads. Say what you are excluding so the interviewer can pull something back in.
Non-functional
- Read-heavy: a user reads far more than they post — assume ~100 : 1 by request count.
- Feed latency: the first page of the feed should render in < 200 ms p95 from the API's perspective; users perceive anything slower as "the app is loading".
- Eventual consistency is acceptable: a post may take a few seconds to appear in followers' feeds. Users must never see a missing post forever, and should not see duplicates.
- Availability over consistency: the feed should degrade (slightly stale) rather than fail. Under CAP terms this is an AP system; see the CAP Theorem subject.
- Scale: hundreds of millions of users; some accounts have tens of millions of followers.