Skip to content
System design course
Ch.4 · Designing real systems·concept ·8 min read

Designing a news feed (Facebook)

Aggregate diverse content from friends, pages, and groups into one ranked feed — the fan-out you know, now with ML ranking instead of pure chronology.

The problem

Design Facebook’s News Feed: a single ranked feed aggregating diverse content (friends’ posts, pages, groups, ads) and ordering it by relevance, not just time. It reuses the fan-out machinery from Twitter/Instagram, but the new ingredient is ranking — deciding which posts and in what order among everything available.

Step 1 — Requirements

Functional: aggregate posts from friends/followed pages/groups; rank them by relevance (engagement likelihood), not strictly chronological; mix media types and ads; support likes/comments/shares.

Non-functional: read-heavy, low-latency feed, scale (billions of users), personalized ranking, eventual consistency OK.

Step 2 — Generation: fan-out, same as before

Building the candidate set reuses the hybrid fan-out (push to friends’ feeds; pull for very high-fan-out sources). Don’t re-derive it — the interesting part here is what happens after you have candidates. (See Twitter for fan-out detail.)

Step 3 — Ranking (the new core)

Instead of reverse-chronological, score each candidate post by predicted relevance to this user and sort:

  • Classic (EdgeRank), conceptually: score = affinity × weight × time_decay
    • Affinity — how close you are to the author (interaction history).
    • Weight — the post type/engagement (a photo with 1000 likes > a plain status).
    • Time decay — newer ranks higher.
  • Modern: a machine-learned model predicts the probability you’ll engage (like/comment/share/dwell) from hundreds of features (author affinity, content type, recency, your history, post popularity), and ranks by expected engagement. Ads are interleaved by a separate auction.

So the feed is: gather candidates (fan-out) → score each with the ranking model → sort → return top-k.

Step 4 — Two-stage ranking for scale

Scoring every candidate with a heavy ML model is expensive, so:

  1. Candidate generation — fan-out produces a few hundred eligible posts.
  2. Lightweight filter — cheap heuristics trim to a few hundred.
  3. Heavy ML ranking — the expensive model scores only those, producing the final order.

This mirrors the search engine’s two-phase ranking — cheap recall, expensive precision.

Step 5 — Architecture

post → fan-out → per-user candidate feeds (post ids)
read → gather candidates → feature fetch → ML ranking service → ordered feed → hydrate + CDN

A ranking service pulls features (from a feature store), scores candidates, and returns the order; the feed is then hydrated (post content, CDN media).

Step 6 — Freshness and feedback

  • Real-time signals — new likes/comments update a post’s features quickly so ranking reflects current engagement.
  • Feedback loop — user actions (hide, like, dwell) feed back as training signal and immediate re-ranking input.

Trade-offs to raise

  • Chronological (simple, transparent) vs ranked (engaging, complex, needs ML + features).
  • Ranking quality vs latency — two-stage keeps it fast.
  • Precompute ranked feed (stale) vs rank at read (fresh, costly) — usually candidate-generate via fan-out, then rank at read for freshness/personalization.

The interview cue

“Generate candidates with the hybrid fan-out (as Twitter), then rank at read with a two-stage pipeline — cheap filtering then an ML model predicting engagement (affinity × weight × recency, modernized to learned features) — interleave ads, hydrate with CDN media. Real-time engagement signals keep ranking fresh.” Fan-out for candidates + ML ranking is the distinguishing answer; implementation next.