Notice Period
system design · week 5

Design a News Feed

The fanout question — push vs pull, and the celebrity who breaks both.

You're asked: "Design the news feed for a social app like Twitter/X or Instagram." Users follow other users; when someone posts, their followers should see it in their feed, newest (or best) first.

This is the fanout interview question. The entire round revolves around one decision — do you build the feed when someone writes a post, or when someone reads their feed? — and the interviewer will keep poking that decision until it bends. Your job is to name the trade-off early, pick a side with numbers, and then handle the case that breaks your pick (spoiler: a celebrity with 100M followers).

How to play it: requirements → estimation → naive pull → fanout-on-write → hybrid for celebrities → ranking and media. If you can narrate that arc with the why at each step, you've answered the question senior engineers get asked at every FAANG loop.

01Requirements & estimation

post / GET /feed◻User⬡Feed System???

Split it the standard way — and notice immediately which side of the system dominates.

Functional

  • Post: a user publishes text + optional image/video
  • Follow: users follow other users (one-directional)
  • Feed: GET /feed returns recent posts from everyone I follow
  • (Clarify) chronological or ranked? — start chrono, add ranking later. Comments/likes? — out of scope today.

Non-functional

  • Read-heavy, brutally so. People scroll far more than they post. Assume 100:1 reads:writes or worse.
  • Feed latency budget: ~200 ms p99. The feed is the product — if it's slow, the app is slow.
  • Eventual consistency is fine. If my friend's post takes 10 seconds to appear in my feed, nobody notices. Say this out loud — it's the permission slip for everything async that follows.
  • High availability over consistency (AP system, in CAP terms).

Back-of-envelope — interviewer says 300M DAU:

  • Posts: ~1 in 10 users posts daily → 30M posts/day ≈ ~350 posts/sec (peak ~1K/sec)
  • Feed reads: each user opens the feed ~5×/day → 1.5B reads/day ≈ ~17K reads/sec, peak ~50K/sec
  • Average followers per user: ~200. But the distribution has a monstrous tail — a celebrity has 100M. Write that down now; it's the landmine of stage 4.
  • Media: posts with images dominate bytes, but media is a separate problem (blob store + CDN, stage 5). The feed itself moves only IDs and text.

The sentence that frames the whole round: "50K feed reads/sec with a 200 ms budget means the feed must be precomputed or cached — we cannot assemble it from scratch on every request." Now prove it.

concept · Read-heavy with a latency budget

When reads outnumber writes 100:1 AND the read path has a tight p99 budget, the design rule is: move work from read time to write time. The whole push-vs-pull debate is just this rule with a name.

concept · Eventual consistency (and why feeds love it)

A feed that shows a post 5–10 seconds late is indistinguishable from a correct feed. Declaring 'eventual consistency is acceptable here' unlocks queues, async fanout, and caches — say it before you draw them.

Checkpoint

1

Why does '50K reads/sec, 200 ms p99' push us toward precomputing feeds?