“Design Twitter” is too big. The first 5 minutes of the interview should narrow scope by negotiating what’s in and out.
Functional requirements
Pick a small core. A safe set:
- Post a tweet (text + optional image/video)
- Follow / unfollow a user
- Home timeline — tweets from people you follow, reverse-chronological
- User timeline — your own tweets
- Like a tweet
Explicitly defer the rest unless the interviewer pushes: search, trending, DMs, retweets/quotes, replies, hashtags, notifications, ads, analytics. Don’t pretend you’ll build all of it.
Non-functional requirements
These shape the architecture more than the features do.
- Read-heavy: timeline reads dominate writes by ~100:1.
- Latency: timeline load < 200ms p99.
- Availability over consistency: stale timelines are fine; outages are not. Eventual consistency for the timeline is acceptable.
- Durability: tweets must never be lost once acknowledged.
Core entities
Before sizing or APIs, name the objects you’re modeling. Fields and storage come later (chapter 4) — for now, just the nouns:
- User — the account: id, handle, profile.
- Tweet — a post authored by a user, optionally with media.
- Follow — a directed edge from follower to followee.
- Like — a user’s reaction to a tweet.
- Timeline — a derived, ordered list of tweets. Two flavors: user timeline (a user’s own tweets) and home timeline (tweets from people they follow).
Timeline isn’t a stored entity in the same sense as the others — it’s computed. Calling it out now is what makes the fanout discussion (chapter 6) meaningful later.
What to confirm out loud
Three questions worth asking the interviewer:
- “Should the timeline be strictly chronological, or ranked?” — Strictly chronological is much simpler. Ranking adds an ML layer.
- “Are we serving global users?” — If yes, you need multi-region replication and edge caches.
- “What’s the scale?” — Anchor on something concrete (e.g. 300M DAU). You’ll use this in capacity estimation next.
The trap
Candidates often dive straight into databases and queues. Don’t. The reason fanout vs. pull is interesting at all is the read/write ratio and the celebrity problem — both of which only exist because of the requirements you set here.
Spend 5 minutes on requirements. Write them on the board. Refer back to them when justifying every later decision.