Twitter System Design
An interview-scoped walkthrough of how Twitter's core subsystems work — each one built up from the naive first-pass answer to the scaled, production-shaped version, the way you'd actually talk through it in a room.
Minute one — before any subsystem
Scoping "Design Twitter"
Twitter has dozens of features. An interview goes better with three: "I'll start here — post a tweet, see a feed of the people I follow, and follow people. That's the whole product in miniature. I'll name what's missing and expand into it once we've nailed this."
The core — say this first
- POST
/api/tweetsThe write. Every other subsystem exists to do something with this one event — deliver it, index it, notify on it. Tweet Ingestion →
- GET
/api/timelineThe read, and the hard problem. This one endpoint is what forces the pull vs. push vs. hybrid conversation — the centerpiece of the interview. Timeline Generation →
- POST
/api/users/{id}/followThe edge connecting the other two. Without it, a “timeline” is just a pile of tweets — this is what makes it personal. Follow Graph →
Expand on later
Named up front so the interviewer knows you know they exist — detailed only once the core holds up, or if they ask. Each one is a real subsystem in this guide.
- Profile timeline
GET /api/users/{id}/tweetsTimeline Generation → - Followers list
GET /api/users/{id}/followersFollow Graph → - Search
GET /api/searchSearch & Trending → - Trending
GET /api/trendsSearch & Trending → - Notifications
GET /api/notificationsNotifications → - Rate limiting
cross-cuttingRate Limiting → - Caching
cross-cuttingCaching Layer →
Explicitly out of scope
- Direct messages — a different read/write and encryption model entirely.
- Ads & monetization — an orthogonal ranking and billing system.
- Spaces / live media — real-time streaming, not a feed problem.
- Payments, video transcoding, multi-region writes — worth naming as real, but follow-ups, not a first pass.
Non-functional priorities
- Read:write ratio. Reads outnumber writes by orders of magnitude — this one fact justifies caching and push fan-out before anything else does.
- Availability over strict consistency. A stale timeline or slightly-off follower count is fine; a failed tweet post or a feed that's down is not.
- Writes never block on fan-out. Posting a tweet returns immediately — delivering it to followers happens asynchronously, off the request path.
How to open with this out loud: name the three core endpoints before drawing a single box, say why each one earns its place, then rattle off the "expand on later" list in one breath — that's what signals you're scoping the problem deliberately, not stalling because you don't know where to start.