Step 1 — Clarify the requirements
Never start drawing boxes. A strong candidate spends the first few minutes scoping the problem so the design that follows is justified. For a news feed, the questions worth asking are:
- Is the feed strictly chronological or ranked by relevance?
- What is the follower distribution: a few celebrities with millions of followers, or fairly uniform?
- How fresh must the feed be: real-time, or is a few seconds of lag acceptable?
- What media types appear (text, images, video) and how big are posts?
Functional requirements
- Publish a post that appears in followers' feeds.
- Fetch a user's feed, paginated, newest or most-relevant first.
- Support follow/unfollow, which changes whose posts appear.
Non-functional requirements
- Feed reads must be fast (the app's home screen blocks on it).
- Eventual consistency is acceptable: a post appearing a few seconds late is fine.
- Scale to hundreds of millions of users with skewed follower counts.
Step 2 — Back-of-the-envelope estimates
Sizing the system tells you which parts are hard. Round aggressively and state your assumptions out loud; the numbers matter less than showing you can reason about scale.
| Metric | Estimate | Reasoning |
|---|---|---|
| Daily active users | ~300 M | Plan for a large social graph; feed reads vastly outnumber writes. |
| Feed reads | ~10:1 vs writes | Users scroll far more often than they post. |
| Average fan-out | hundreds, tail in millions | Most users have hundreds of followers; celebrities have millions, which dominates cost. |
Step 3 — Data model and API
A compact data model and a small API surface anchor the rest of the discussion. Keep both minimal; you can always extend them when the interviewer pushes.
Core entities
posts
post_id (PK), author_id, content, media_url, created_at
Immutable feed items; shard by post_id or author_id.
follows
follower_id, followee_id, created_at
The social graph; queried both directions, so index both.
feed_cache
user_id -> ordered list of post_ids
Precomputed per-user timeline (the fan-out-on-write store).
API sketch
- POST
/api/v1/posts— Create a post and trigger fan-out. - GET
/api/v1/feed?cursor=— Return the next page of the caller's feed. - POST
/api/v1/follow— Follow a user (mutates the graph).
Step 4 — High-level design
Sketch the happy path end to end before optimising anything. This is the architecture you would draw on the whiteboard first:
- 1A write goes to the post service, which stores the post and enqueues a fan-out job.
- 2The fan-out worker writes the post id into each follower's precomputed feed (fan-out on write).
- 3A feed read returns the precomputed list from cache, then hydrates post details.
- 4For celebrities, skip precompute and merge their posts in at read time (hybrid).
Step 5 — Deep dives that separate strong answers
The high-level design is table stakes. Interviewers spend most of the time here, probing the decisions that actually carry the system. These are the ones to be ready for.
Fan-out on write vs fan-out on read
Fan-out on write (push) precomputes each user's feed when a post is created, so reads are a cheap lookup of an already-built list. This makes the common case (reading) fast but makes writes expensive: a post from someone with a million followers triggers a million feed insertions. Fan-out on read (pull) does the opposite: store posts once and assemble each feed on demand by querying the accounts a user follows. Reads become expensive (a fan-in query plus a merge sort) while writes are cheap. Neither is right alone; the production answer is a hybrid.
The celebrity problem and the hybrid
Pure push collapses when an account has millions of followers because a single post causes a write storm and may never finish before the next post. The standard fix: use push for normal users (cheap fan-out, fast reads) and pull for celebrities (do not fan their posts out; instead, at read time, merge a celebrity's recent posts into the requesting user's precomputed feed). This bounds write amplification while keeping reads fast for the vast majority of accounts. Define the threshold (e.g. follower count over some limit) explicitly.
Ranking and freshness
A chronological feed is a merge of timestamps; a ranked feed scores each candidate post on engagement signals, recency, affinity, and content type, then sorts. Ranking adds a feature-extraction and scoring stage usually backed by a model service. Whatever the ordering, the feed cache holds post ids only and details are hydrated from the post store and a CDN for media, so the cache stays small and posts can be edited or deleted in one place.
Step 6 — Bottlenecks and how to scale past them
Naming where the design breaks, and the specific fix, is what signals seniority. For a news feed the pressure points are:
Write amplification from high-fan-out accounts.
Hybrid push/pull: pull for celebrities, push for everyone else.
Hot feed-cache shards for popular users.
Replicate hot entries; cap stored feed length and paginate beyond it from source.
Media bandwidth.
Serve images/video from a CDN; store only references in the feed.
Step 7 — Key tradeoffs
There is rarely one right answer. State the tradeoff, then commit to a side with a reason tied to the requirements you clarified in step one.
Fan-out strategy
Push (fast reads, costly writes)
Pull (cheap writes, costly reads)
Guidance: Hybrid: push for normal users, pull for celebrities, threshold by follower count.
Ordering
Chronological (simple, predictable)
Ranked (higher engagement, complex)
Guidance: Start chronological; add ranking as a separate scoring stage when engagement is the goal.
Common follow-up questions
When you finish the core design, expect the interviewer to pull on one of these threads. Have a one-paragraph answer ready for each.
- How do you handle a user who follows tens of thousands of accounts?
- Fan-out on write (push) precomputes each user's feed when a post is created, so reads are a cheap lookup of an already-built list. This makes the common case (reading) fast but makes writes expensive: a post from someone with a million followers triggers a million feed insertions. Sketch the change against the high-level design above and tie your choice back to the requirements you clarified, rather than reaching for the most complex option.
- How do edits and deletions propagate to already-fanned-out feeds?
- Pure push collapses when an account has millions of followers because a single post causes a write storm and may never finish before the next post. The standard fix: use push for normal users (cheap fan-out, fast reads) and pull for celebrities (do not fan their posts out; instead, at read time, merge a celebrity's recent posts into the requesting user's precomputed feed). Sketch the change against the high-level design above and tie your choice back to the requirements you clarified, rather than reaching for the most complex option.
- How would you add stories or ephemeral content with a TTL?
- A chronological feed is a merge of timestamps; a ranked feed scores each candidate post on engagement signals, recency, affinity, and content type, then sorts. Ranking adds a feature-extraction and scoring stage usually backed by a model service. Sketch the change against the high-level design above and tie your choice back to the requirements you clarified, rather than reaching for the most complex option.
- How do you keep the feed consistent across a user's devices?
- Fan-out on write (push) precomputes each user's feed when a post is created, so reads are a cheap lookup of an already-built list. This makes the common case (reading) fast but makes writes expensive: a post from someone with a million followers triggers a million feed insertions. Sketch the change against the high-level design above and tie your choice back to the requirements you clarified, rather than reaching for the most complex option.