Subscribe Now.. Here’s what’s included:
→ Every Tuesday paid walkthrough — one full named-question answer every week, calibrated to L4–L7. 52 posts per year.
→ All drill cards — single-page PDFs for each question, designed to be re-read the morning of your interview
→ The full paid archive — every walkthrough ever published, available immediately
→ Framework cheatsheets — estimation numbers, API design patterns, trade-off communication, scaling decisions
→ Discord community — #ask-the-author, mock interview partners, #offers-landed
This is the question that defines the social feed archetype. Twelve questions in the FAANG question bank are variants of this one — Instagram feed, TikTok For You, Reddit front page, LinkedIn news feed, Pinterest home, YouTube next-up, Stories, trending topics. They share a backbone: many users, many posts, a feed that has to be both fresh and ranked, and a write/read ratio that decides the entire architecture. If you internalize Twitter timeline, you can answer eleven other questions you haven’t drilled.
The version most interviewers ask is not “design Twitter” — that’s a 4-hour question. They ask “design the Twitter home timeline” or “design the news feed for [our product]” or “design the part of [X] that shows posts from people you follow.” All of these collapse to the same probe: how do you serve a feed for a user whose followed set has wildly variable size and post rate, while keeping the feed fresh?
For L4 / mid-level the bar is articulating one approach (fanout-on-write) and walking it cleanly. For L5 / senior, the probe is the trade-off between fanout-on-write and fanout-on-read, and the realization that production systems do both depending on the user. For L6 / staff, the probe is hot-user handling, ranking, and the operational story for a system that ingests millions of writes per second and serves billions of feed reads.
The Question
“Design the Twitter home timeline. A user opens the app and sees a feed of recent posts from the people they follow, sorted appropriately. Posts can be original tweets, retweets, or replies.”
Common variants:
“Design Instagram’s feed.”
“Design Facebook News Feed.”
“Design the LinkedIn home page.”
“Design Reddit’s front page.”
“Design the TikTok For You feed.”
The first four are direct equivalents. TikTok For You is almost the same — but with one critical difference: it’s not a follow-graph feed, it’s a recommendation feed. The architecture is similar; the candidate generation is different. Note this if asked.
Step 1 — Clarify Before You Draw
Six questions. The first three matter most.
1. Are we ranking or just chronological? Old Twitter was reverse-chronological. Modern Twitter is ranked. This is the single biggest variable. Chronological is far simpler — sort by timestamp, done. Ranked introduces a scoring system, a feature pipeline, and probably an ML model. State which one you’re designing for explicitly. If unclear, design ranked — it’s the harder and more realistic version.
2. What’s the active user count? What’s the average follow count? What’s the maximum? The numbers determine the architecture. 100M daily active users with average follow count 200 looks different from 500M DAU with average follow count 500. The maximum follow count is the more decisive number — it’s the long-tail celebrity problem in disguise. State explicit numbers.
3. What’s the read-to-write ratio? Always lopsided in social feeds, but how lopsided matters. 100:1 means you have lots of writes; 1000:1 means you can afford to do work on the write path. State the ratio; it justifies fanout-on-write later.
4. How fresh? Real-time, or 5-minute staleness OK? Real-time means push. Stale-OK means pull or hybrid. Most production feeds tolerate seconds-to-minutes of staleness; saying “I’d target 5-second p99 freshness” is a senior signal.
5. What goes in the feed besides original posts? Retweets count as posts, generally. Replies usually don’t appear in the home timeline by default (only on the conversation thread). Trending topics, ads, suggested follows, “in case you missed it” pulls — all of these are injected into the feed in production. Acknowledge this exists; don’t try to design it all.
6. What’s the SLO for feed load? Typical: p50 < 200ms, p99 < 500ms for the API. The user opens the app and the timeline has to be there. State the number; it drives caching.
Step 2 — Estimate
Working assumptions for the rest of this walkthrough:
500M daily active users (DAU)
Each user reads their feed ~5 times/day on average → 2.5B feed reads/day → ~30K reads/sec average, peaking at 200K
Each user posts ~0.2 times/day on average → 100M posts/day → ~1,200 posts/sec average, peaks at ~10K
Average follow count: 200 (median is much lower; mean is dragged up by power users)
Maximum follow count: 5,000 (for normal users; verified accounts can exceed)
Maximum follower count: 100M+ (for celebrities — this is the asymmetry that breaks naive designs)
Posts retained in timelines: roughly 1,000 per user (older items can be paginated in on demand)
Storage:
Posts table: 100M posts/day × 365 days × 5 years × 1 KB ≈ 180 TB
Timeline cache (precomputed timelines): 500M users × 1,000 posts × 200 bytes/entry ≈ 100 TB
Follow graph: hundreds of billions of edges, but each edge is small (~30 bytes) → ~3-5 TB
The timeline cache is the unusual one. It’s bigger than your hot OLTP and lives in a different system (typically Redis, Memcached, or a custom in-memory store). When a senior candidate names this layer separately from the posts store, you know they’ve built something like this.
Read bandwidth:
200K reads/sec × 1,000 timeline entries × 200 bytes ≈ 40 GB/s
This is what the timeline cache absorbs — the posts table never sees this traffic.
Step 3 — API Design
Three endpoints. The first one is the headline.
GET /v1/timeline/home
Query:
cursor: string (optional, for pagination)
limit: integer (default 20, max 100)
Response:
posts: [array of post objects]
next_cursor: string or null
ranked_at: timestamp (when this version was ranked)
POST /v1/posts
Body:
content: string (max 280 chars or whatever your limit is)
media_ids: [array of pre-uploaded media references]
reply_to_post_id: optional
Idempotency-Key: header
Response:
id, created_at, author_id
POST /v1/follow
Body:
target_user_id: string
Response:
follow_id, created_at
Pagination is cursor-based, not offset-based. Offset (page=3, per_page=20) is broken at scale because the data shifts beneath you — by the time you fetch page 3, new posts have arrived and pushed everything down. Cursors (an opaque token encoding a position in the feed) are immune to this. Saying “cursor-based, never offset-based for feeds” is a senior signal.
ranked_at in the response is the time the timeline was scored. Useful for client-side caching (”don’t re-fetch for 30 seconds”) and for debugging staleness reports. Most candidates omit this. Including it is a small but real senior tell.
Subscribe now to
→unlock complete system design walkthroughs
→ Get access to downloadable Drill Cards and full walkthrough
