A feed is a question with three answers: do you build each follower’s timeline when the author posts (push), when the reader opens the app (pull), or both (hybrid)? The entire interview pivots on that single decision and on the one input that breaks the naive answer: the celebrity with a hundred million followers. This playbook scripts the loop end to end for the most-asked question in the canon.
Every FAANG company runs a rubric. The dimensions are roughly the same; the weights differ by company and level. At senior+ the boxes-and-arrows are table stakes — what gets graded hardest is the quality of your decisions: the questions you asked first, the trade-offs you surfaced and defended, and the production reality you volunteered without being asked.
| Dimension | Weight | What earns the signal |
|---|---|---|
| Requirements & scoping | 10–15% | You scoped before drawing, asked enough to bound the problem, pinned the scale number, and stated assumptions out loud. |
| High-level architecture | 20–25% | The right components, a clear data flow, and a reason every box exists. The design satisfies each functional requirement. |
| Technical depth / deep dives | ~30% | You go three questions deep on the hard part without being rescued. This is where staff is won or lost. |
| Trade-offs & judgment | highest effective | Two viable options, what each costs, and a committed pick for this system. Simplicity over flash when flash isn't warranted. |
| Communication / driving | cross-cutting | You drive the 45 minutes; the interviewer never has to rescue you. You narrate, checkpoint, and narrow when the design sprawls. |
| Operational maturity | ↑ in 2026 | The newest weight: observability, rollout, failure modes, on-call reality — volunteered, not pried out. |
A solid design with reasonable trade-offs is a strong score for a mid-level candidate and a downlevel flag for staff. The questions can be identical; the depth expectation is not. As you climb, the balance tips from breadth toward depth, proactivity, and production reality.
You don't recite AWS — you anchor each decision to one of these. It signals you evaluate systems across competing concerns rather than optimizing one axis. Each pillar below is mapped to a move you can make in this exact design.
Run and observe the fan-out pipeline.
Protect the graph and abuse surface.
Survive the celebrity spike.
Keep the read path cheap.
Don’t materialize what nobody reads.
Bound the working set.
This is the high-level design the interviewer wants on the board by minute 20. Two paths share one cache: a write path that fans ordinary authors out to their followers' materialized timelines, and a read path that serves those timelines in a single lookup — then merges in the handful of celebrity posts that were deliberately not fanned out. Trace the arrows out loud as you draw them and the whole design narrates itself.
The simulation. Framing throughout: a Twitter-scale feed — ~300M DAU, ~500M posts/day, a read-heavy workload around 100:1, home-timeline reads targeting p99 < 200ms, eventual consistency acceptable.
Split the write path (posting) from the read path (viewing the home timeline) immediately — they have wildly different volumes and that gap is the heart of the problem.
p99 < 200ms.“Before I design — is this chronological or ranked? And do we have celebrity accounts with tens of millions of followers? Those two answers change the architecture more than the scale number does.”
“This is read-heavy by roughly 100:1, so I’ll optimize the read path even at the cost of doing more work on write. That single asymmetry is what pushes us toward precomputing feeds.”
“Let me start drawing.” Jumping to boxes before naming the read:write ratio means you’ll design the wrong path well.
Design Twitter.
Let me scope. Core actions: post, follow, and read a home timeline. The defining feature is that reads vastly outnumber writes, so I’ll optimize reads. Two questions that’ll shape everything: chronological or ranked, and do we have celebrity-scale accounts?
Chronological for now. Yes, celebrities exist.
Then the celebrity case is my central design constraint, and I already know pure push won’t survive it. Let me build the simple version first and evolve into a hybrid.
Three entities: User, Tweet (id, authorId, body, ts), and the Follow graph (follower → followee edges). Two endpoints carry the product:
Fan-out cost = average followers × posts/sec. If the average user has a few hundred followers, each post is a few hundred feed writes — cheap. But a celebrity with 100M followers turns one post into 100M writes. State that asymmetry out loud: it’s the entire justification for going hybrid.
“Pagination uses an opaque cursor keyed on tweet ID, not an offset — the feed changes under the reader, and offsets would skip or repeat tweets as new ones arrive.”
Designing a heavy normalized SQL schema for tweets. The interesting data here is the feed and the graph, not a third-normal-form tweet table.
Start with the simplest thing that satisfies the requirements, then let its weakness pull you forward.
Store tweets in a tweet store; store the follow graph. On getHomeTimeline, look up everyone the user follows, fetch their recent tweets, merge-sort by time, return the top N. It works — and it’s a great starting point because you can immediately name why it doesn’t scale: a user following 5,000 accounts triggers a 5,000-way scatter-gather on every single feed open. On the hottest path. At 100:1 reads.
Flip the work to write time. Maintain a materialized home timeline per user in Redis (a capped list of tweet IDs). When someone posts, asynchronous fan-out workers (fed by Kafka) append that tweet ID to each follower’s cached feed. Reads become a single cache lookup — exactly what the hot path needs.
“I’ll precompute feeds on write for normal accounts so reads are one lookup. But I’ll cap fan-out: above a follower threshold, an account is ‘pull’ — we don’t fan their posts out, we merge them at read time.”
Pure pull “because writes stay cheap.” Defensible only if reads are rare or feeds tiny — say so. For a read-heavy social feed it’s the wrong default; name why before dismissing it.
“We’ll just fan out every post to every follower.” Without the celebrity carve-out this collapses the moment the interviewer names a popular account.
Classify accounts by follower count. Below the threshold: fan out on write into follower feeds (fast reads). Above it (celebrities): do not fan out; store their recent posts separately. On read, take the user’s materialized feed and merge in the latest posts from the handful of celebrities they follow, sorted by time. This bounds write amplification without making the common-case read a scatter-gather. The cost: read becomes “cache + a few small fetches” instead of one lookup — a deliberate, defensible trade.
Ranking turns the merged list into candidates. Add a feature store and an online scoring layer: generate candidates (followed + some recommended), score thousands of them in a few milliseconds against precomputed features, return the top slice. Precompute heavy features offline; keep the online path lean to hold the latency budget.
“The write-amplification math is the whole game: hybrid trades a slightly more expensive read for a bounded write. I’d roll a ranking change out as a canary on a small traffic slice, watching engagement and p99 before widening — a bad ranker degrades the product silently.”
“We’ll add more Redis.” Capacity without the hybrid carve-out doesn’t fix the celebrity write storm — it just spreads it.
A celebrity with 100M followers tweets. Trace it.
That account is above my fan-out threshold, so the post is not fanned out — it’s written once to a celebrity-posts store. No write storm. Their followers pick it up at read time: when any of them opens their timeline, I merge that celebrity’s recent posts into their materialized feed before returning.
Doesn’t that make reads slower for everyone?
Only by the cost of merging a handful of celebrity posts — most users follow very few mega-accounts. I’m trading a small, bounded read cost for eliminating an unbounded write cost. If a user somehow followed thousands of celebrities I’d cache the merged result briefly, but that’s a rare tail.
Threshold changes (who counts as a celebrity) and ranking changes go out as canaries with a fast rollback. Keep the chronological path as a fallback if the ranker misbehaves.
“With more time I’d dig into media storage and the recommendation/candidate-generation side. I scoped those out deliberately — I didn’t miss them.”
Interviewers rarely accept the first answer — they push to find the edge of your fan-out reasoning. Answer the question asked, give the reasoning, then stop.
All three are valid for different shapes. Push gives O(1) reads but unbounded writes on popular accounts. Pull gives cheap writes but expensive scatter-gather reads. For a read-heavy social feed with celebrities, hybrid wins: push for normal accounts, pull-and-merge for the few mega-accounts. I commit to hybrid and name the celebrity threshold as the dividing line.
Cap each feed to ~800 recent tweet IDs; older history regenerates from the tweet store on demand. TTL dormant users and rebuild lazily on next login. That bounds memory to active users × cap, independent of total user count.
Ranking turns the merged feed into a candidate set scored by an ML layer. I add a feature store and an online scorer that ranks thousands of candidates in a few ms using precomputed features. The fan-out machinery stays; I just insert a scoring step on read and broaden candidates beyond strict follows.
Cursor-based, keyed on tweet ID or a snapshot timestamp — never offset. An offset would skip or duplicate tweets as new ones arrive at the head. The cursor anchors the reader to a stable point in the timeline.
That's exactly why normal accounts are push: their tweets are already in this user's materialized feed, so following 5,000 normal accounts costs nothing extra at read time. Only the celebrity subset is merged on read, and that set is small. Pull-everything is the design I rejected for this reason.
Eventually consistent — seconds of lag is invisible to users and lets me make fan-out asynchronous and the system highly available. I'd never trade availability or read latency for making a tweet appear a few hundred milliseconds sooner.
A clean design with one of these undercurrents still scores below the bar at senior+. None are about getting an answer wrong — they're about how you operate.
Jumping to architecture without bounding the problem or confirming scale. Reads as template-matching.
"It depends" with no decision behind it. Name the trade-off, then pick.
Stalling at the core deep dive until the interviewer feeds you the answer. Depth is the senior+ bar.
Committing to fan-out-on-write without naming the write storm a popular account creates. The interviewer is waiting for the carve-out.
Reveals you haven't thought about a feed that mutates at the head while the user scrolls.
No observability, no rollout, no failure-mode plan. In 2026 this reads as "has never carried a pager."
Confident wrong answers when pushed. Far worse than an honest "here's what I'd verify."
Waiting to be asked the next question. At staff you own the 45 minutes.
Run a mock and score yourself honestly against the dimensions the interviewer uses. If you can't hit "strong" on depth and operability, that's your signal on where to drill.
| Dimension | Weak (downlevel) | Strong (at level) |
|---|---|---|
| Scoping | Started drawing; missed the read:write ratio. | Named ~100:1 reads, asked chronological-vs-ranked and celebrities up front. |
| Fan-out choice | Picked push or pull with no trade-off. | Committed to hybrid with the celebrity threshold and the write-amplification reasoning. |
| Celebrity handling | Needed a hint; had no plan. | Raised it unprompted; pull-and-merge for mega-accounts, push for the rest. |
| Feed cache | Unbounded cache; never mentioned eviction. | Capped feeds, TTL'd dormant users, separated viral-tweet read hot keys. |
| Ranking awareness | Didn't know what ranked adds. | Described feature store + online scoring over candidates within the latency budget. |
| Operability | Never mentioned it. | Volunteered fan-out-lag SLO, cache-hit dashboards, canary rollout of ranking. |