Playbook / General system design / Design a news feed / ranking system

Design a news feed / ranking system

Expected question

"Design a news feed / ranking system. How do you ingest posts, rank content per user, and serve a fresh feed at scale?"

Variant forms

Same design, different framing:

  • "Design Facebook/Instagram-style home feed for 1B users."
  • "How do you blend chronological, social graph, and ML-ranked content?"
  • "Design fan-out on write vs fan-out on read for celebrity accounts with 50M followers."
  • "Our feed feels stale — architect near-real-time ranking feature updates."
  • "Design exploration vs exploitation to surface new creators without hurting engagement."
  • "How do you A/B test ranking models without inconsistent user experiences?"
  • "Design feed caching and pagination for infinite scroll with consistent ordering."

Where this actually gets asked

Well-documented for Meta specifically: "Design Instagram" is repeatedly cited, independently, across multiple prep sources (IGotAnOffer, Exponent, DesignGurus) as one of Meta's most commonly asked system-design questions — no single verbatim Blind quote was captured, but the cross-source convergence is credible given Meta's own consumer feed products. No evidence was found for Google, Microsoft, Apple, OpenAI, or Anthropic asking a comparable feed-ranking question — unsurprising, since none of these companies has a consumer feed product as central to its business as Meta's. The real-system grounding here is strong: Meta's own engineering blog published "Serving Facebook Multifeed: Efficiency, performance gains through redesign" (2015), describing the real Aggregator/Leaf/ Tailer architecture, and "News Feed ranking, powered by machine learning" (2021), describing the real candidate-generation → ranking → post-ranking pipeline.

Executive summary

30-second thesis

I'd default hybrid fan-out — push for normal accounts, pull for celebrities — then candidate-gen → rank → diversity/integrity, not one chronological list.

2-minute answer

Clarify DAU, follow-graph fanout skew, and whether ranking is ML or heuristic. Default: write-path fanout into follower feed caches for bounded accounts; celebrity posts stay on author timeline and merge at read. Ranking is staged: cheap candidates, expensive L2 score, post-rank diversity/safety. Author must see their own post immediately (write-through); followers can tolerate seconds of staleness (H). Under load shrink candidate pools / serve cached page with refresh — never skip ACL/visibility. Engagement-only metrics lie; say how you'd eval quality beyond clicks.

Quantitative trade-offs

DecisionTrade-off and reversal evidenceEvidence class
Fanout-on-write vs hybridPure push melts on 100M-follower posts; reverse celebrities to pull when write amplification exceeds budget.R/H
Heavy L2 ranker vs cached pageRanker improves relevance; reverse to cached/heuristic when p99 feed load blows the interactive budget (H).H
Engagement vs diversity post-rankEngagement alone creates filter bubbles; reverse weight when integrity/diversity evals regress.H

What I'd ask them

  1. What fraction of posts come from accounts above ~1M followers?
  2. Is chronological still a product mode, or ranking-only?
  3. What's the p99 feed-load budget and author read-after-write expectation?

Requirements

Functional

  • A user's feed shows content from people/pages they follow, ordered by relevance (not strictly chronological).
  • New content should appear in relevant followers' feeds within a reasonable delay — not necessarily instant, but not hours late either.
  • Support a "celebrity" case: some accounts have hundreds of millions of followers, which a naive design would handle identically to a normal user and buckle under.

Non-functional

  • Read-heavy at extreme scale — most users check their feed far more often than they post, making read-path efficiency the dominant design concern.
  • Ranking needs to run fast enough to feel instant on feed load, even though it's evaluating a large candidate pool per request.
  • The celebrity/fan-out problem is a real, asymmetric scaling concern — a small fraction of accounts generate a disproportionate share of total fan-out work.

Core entities

  • Post: author, content, timestamp, engagement signals (likes, comments, shares) used as ranking features.
  • Follow graph: who follows whom — the basis for whose posts appear in whose feed.
  • Feed entry: a (user, post) pairing representing "this post is a candidate for this user's feed," with a computed relevance score.
  • Ranking model: consumes engagement signals, follow-graph proximity, and recency to score candidate posts per user.

API / interface

Auth: end-user token; ranking features never accept client-trusted scores.

GET /v1/feed?cursor=eyJ...&limit=20
→ 200 {"items":[{"post_id":"p_...","score":0.81,"reasons":["affinity","recency"]}],"next_cursor":"..."}

POST /v1/feed/events
{"post_id":"p_...","event":"impression|click|hide","request_id":"req_...","position":3}
→ 202 {"accepted":true}

POST /v1/posts
{"author_id":"u_...","body":"...","visibility":"friends"} → 201 {"post_id":"p_..."}

GET /v1/feed/debug/{user_id}   # staff-only
→ {"candidate_sources":["friends","groups"],"ranker":"v7","excluded":[{"post_id":"...","reason":"seen"}]}

Staff+ callout: feed read is cursor-based; ranking debug is a privileged API for incident response.

Data Flow

Candidate generation → rank → blend → cache; client feedback trains the next ranker iteration.

Rendering architecture diagram…

High-level design

Rendering architecture diagram…

This is Meta's own real, published architecture pattern (the Aggregator/Leaf/Tailer design): separate the fan-out mechanism by author type rather than using one uniform strategy for every post.

Deep dive 1: fan-out-on-write vs. fan-out-on-read — the celebrity problem

ApproachWrite costRead costWhen it's the right call
Fan-out-on-write (push to every follower's feed cache at post time)High for accounts with huge follower counts — one post = millions of writesVery low — reading a feed is just reading a pre-computed cacheThe default for normal accounts with a bounded, reasonable follower count
Fan-out-on-read (compute the feed at request time by pulling from followed accounts)Low — a post is written onceHigher — every feed load must query and merge from many followed accountsNecessary for celebrity/huge-follower-count accounts, where fan-out-on-write would be prohibitively expensive per post
Hybrid (Meta's real, documented pattern)Fan-out-on-write for normal accounts; fan-out-on-read for celebrity accounts, merged at aggregation timeBest of both, at the cost of a more complex aggregation layerThe actual real-world answer — treating this as one uniform strategy is the common mid/senior-level gap

Trap: proposing pure fan-out-on-write as the entire answer, without recognizing that a single post from an account with 100M+ followers would require 100M+ individual cache writes at post time — a catastrophic write amplification that real systems specifically design around via the hybrid approach above.

Deep dive 2: ranking as a separate, ML-driven stage

A common weak design stops at "show posts in reverse-chronological order." Meta's real, published ranking pipeline (per its 2021 engineering blog) runs a genuine multi-stage process: candidate generation (pull a bounded set of recent/relevant candidates, not the full history), a ranking model (scores candidates using engagement-prediction signals — likelihood of like/ comment/share, recency, relationship strength to the viewer), and post-ranking adjustments (diversity — not showing 10 posts from the same author consecutively, integrity/safety filtering). Trap: treating ranking as a single sort-by- recency-and-engagement-score step, missing that real systems separate candidate generation (a cheap, broad first pass) from ranking (an expensive, narrow scoring pass) specifically to keep the expensive step's input size bounded.

Deep dive 4: author read-after-write and feed latency budgets

After a post, the author must see their own content immediately (write-through or merge-on-read) even if follower feeds tolerate seconds of staleness. Define a p99 feed-load budget; under load, shrink candidate pools / skip expensive L2 / serve cached page with background refresh — and observe which tier served. In 45 minutes, nail hybrid fan-out + ranking stages; don't rebuild ads.

What's expected at each level

  • Mid-level: proposes pure fan-out-on-write with simple reverse-chronological ordering, without addressing the celebrity/high-follower-count case.
  • Senior: identifies the celebrity fan-out problem and proposes a fan-out-on-read fallback for high-follower accounts.
  • Staff+: designs the hybrid aggregation layer explicitly (merging pre-computed and on-read-computed candidates), and separates candidate generation from ranking as distinct pipeline stages.
  • Principal: additionally reasons about ranking model feedback loops (engagement-optimized ranking can create filter-bubble or addiction-pattern side effects) and discusses where diversity/integrity post-ranking adjustments belong in the pipeline as a deliberate counterbalance, not an afterthought.

Follow-up questions to expect

  • "Breaking news should temporarily override ranking?" — Don't pretend the main model "notices." Add a time-boxed boost in candidate generation (or a dedicated injector) with an expiry, then go back to normal ranking.
  • "How do you know a ranker change is actually better?" — Engagement alone will reward addiction. Gate on a slice set that includes quality/integrity, not just CTR — same eval discipline as ai-system-design/07.
← Design a real-time chat/messaging system at scaleDesign a distributed job scheduler / task queue →