Design Facebook Feed

Introduction

If you have only one mental image for this problem, make it skew: almost everyone reads, almost nobody posts, and a handful of accounts have more followers than some countries have people. The home feed is “posts from the graph, in some order, fast”—the boring part is storage; the interesting part is not doing unbounded work when someone scrolls or when a celebrity hits Post.

Interviewers are not grading your ability to draw eleven boxes. They want to hear you name the hot paths, split push vs pull without hand-waving, and admit where consistency gets fuzzy (pagination + ranking + graph churn). If you can do that in plain language, you are already ahead of the template answers.

How to approach

Treat the first minutes as a negotiation, not a quiz. Ask what “feed” means (home only vs groups), whether ranking is in scope, and what “fresh” means in seconds—not because you need permission to be smart, but because your tradeoffs change if the answer is “purely chronological” vs “Top stories with ML.”

Then sketch capacity in one pass: reads vs writes, rough fan-out per post for a normal user vs a page, and where the fire starts (mailbox shards, fan-out queue, ranker). After that, walk one write (post created → durable → async fan-out) and one read (load candidates → merge → rank → page) before you let yourself drown in storage brands.

If time is short, prioritize celebrity policy and pagination under changing rank—those are the questions that separate “I read a blog post” from “I’ve thought about production.”

Interview tips

Say where the graph lives and what you cache. Say where post bodies live vs feed IDs. Say fan-out is async and idempotent so retries do not duplicate in mailboxes.

When you mention Kafka or a queue, tie it to backpressure: what you measure when workers fall behind. When you mention ranking, separate candidate generation from scoring and pick a freshness story you can defend.

Expect to be pressed on blocks and unfollows—a crisp answer admits brief staleness but never hand-waves safety. Expect “what if the ranker is slow?”—timeouts and recency fallback beat heroic blocking.

Capacity estimation

Rough numbers to anchor the whiteboard (tune in the room):

Input	Order of magnitude
DAU	500M+ (from problem spec)
Home feed reads per DAU	Tens to hundreds per day (people open the app often, not every scroll is a full refetch)
Writes (new posts) per day	Hundreds of millions globally → write QPS is modest vs read QPS
Follow graph	Highly skewed: median user hundreds of follows; P99 and celebrities dominate cost

Implications: You cannot do O(followers) work on every read. You shard mailboxes or cap pull-merge. You async fan-out. You bound candidate pools before ranking so p95 stays in range.

High-level architecture

At a whiteboard, you need a story, not a catalog. One reasonable story: traffic hits edge + API (TLS termination, auth, rate limits, request IDs); a feed service owns “give me the next page of the home timeline”; it pulls candidate post IDs from per-user storage (mailboxes and/or on-read merge), batch-loads post bodies and author metadata, applies safety filters (blocks, policy), then hands a bounded candidate set to a ranker with a hard time budget. Nothing in that sentence assumes a single database or a monolith—only clear ownership of each hop.

Who owns what (typical split):

• API / BFF — Session or token validation, coarse routing, timeouts to downstreams, sometimes response shaping so the mobile client is not fanning out to twenty microservices.
• Feed service — Orchestrates read path: assemble candidates, call graph for “who can this viewer see?”, call post store for bodies, call ranker, return cursor + hydrated posts. It is where you cap work (max candidates, max fan-out depth).
• Mailbox / timeline store — Durable ordered lists of post IDs (or score+id tuples) per viewer, often sharded by user_id. This is not the full post body store.
• Post service + object storage — Source of truth for post metadata (author, created_at, privacy, media keys). Blob/video live in object storage; CDN serves bytes; URLs in API responses are usually signed or stable ids resolved at read time.
• Graph service — Follow / unfollow / block / mute edges; heavily cached at the edge of the feed path because every home read touches it.
• Fan-out workers — Consumers off a queue or log: given (post_id, author_id), append to follower mailboxes where push is in policy. Work is at-least-once; writes are idempotent (viewer_id, post_id) so retries do not duplicate.
• Ranker / scoring — May be embedded in feed svc or separate; often feature/log fetches first, then score. Treat it as best-effort within SLA, not a synchronous join to every offline job.

Where caching sits: Hot post bodies, author profiles, and graph “following set” snapshots are common cache layers—often between feed orchestration and the durable stores. Say what is safe to serve stale (profile display name) vs not (block list for safety).

Celebrity / hybrid on the diagram: For authors you do not fully fan out, the feed service still merges recent posts by author id (or pulls from an author-indexed store) into the candidate pool. Label that edge on the whiteboard—otherwise the diagram only shows push fan-out and you get the follow-up you deserve.

[ Client ]
    → [ LB / API gateway ] → [ Feed svc ] → [ Cache? ] → [ Mailbox store / merge ] → [ Ranker ] → response
                                 ↑              ↑
                                 |              +-- optional: recent-tail / author merge (hybrid)
                                 |
                    [ Graph svc ]--+  (follows, blocks)
                                 |
          [ Post svc ] ←---------+  (metadata, not media bytes)
                |
                +→ [ Fan-out queue ] → workers → mailboxes (per-viewer timeline shards)
                |
                +→ [ Object store ] → [ CDN ]  (media)

In the room: Narrate the read path first (latency budget, bounded candidates, ranker timeout). Then one write (durable post → async fan-out → idempotent mailbox writes). Interviewers often let you fill in storage brands once they believe you will not fan-out 100M rows on every post.

Core design approaches

Fan-out on write (push)

After a post is stored, push its ID into each follower’s mailbox (per shard). Reads feel cheap because the heavy work already happened.

The catch is the O(followers) wall. The moment you say “we fan out to everyone,” you owe the room a celebrity exception—or you have accidentally designed a distributed denial-of-service machine that charges you money.

Pull on read

At request time, pull recent posts from followed accounts and merge. That dodges the celebrity write blast, but you can spend a lot of CPU merging wide fan-in if someone follows thousands of accounts—so real systems cap, cache, or hybridize.

Hybrid (what production usually sounds like)

Push for the long tail where fan-out is cheap. For mega-followed authors, do not materialize every edge—merge their recent posts on read, or fan-out only to “active” mailboxes, or store by author and intersect. The exact policy matters less than saying there is a policy and naming the cost driver (queue depth, storage, blast radius).

Detailed design

Write path

Walk it like you are explaining an outage retro: media lands in object storage; the post row gets durable metadata; the client gets success without waiting for every follower’s mailbox row. Fan-out runs as async work with idempotency so retries do not duplicate (post_id → mailbox) inserts.

Everything else—search indexing, notifications, ugly link previews—can trail behind. If you put those on the critical path, you will miss latency and still get the wrong Open Graph image sometimes.

Read path

This is the path that actually matters for “how does Facebook feel fast?” Load a chunk of candidate IDs for the viewer (precomputed + optional recent tail if you hybridize), multi-get bodies and authors, filter blocks and hard safety rules, then rank under a time budget and return a cursor that survives the next request.

If you only say “we call the ML service,” follow up with what you do when ML is slow—because that is what your on-call cares about.

Key challenges

• Skew: One author, 100M followers—fan-out on write is a storage and queue blast radius.
• Pagination vs ranking: Order changes between requests; cursors and occasional dup/skip are expected—don’t fake strong consistency.
• Graph churn: Unfollow/block must become visible without infinite recomputation—TTL, lazy filter, compensating deletes.
• Ranking lag: Scores can be seconds stale; product and safety need explicit contracts.

Scaling the system

Caching is not a vibe; it is a list of keys that catch fire. Hot posts, hot profiles, and “everyone requests the same post ID at once” are where you add request coalescing and TTL jitter. Sharding is usually mailboxes by user_id, posts by id or author-time, and no joins on the hot read path.

Multi-region is almost always “read mostly local, accept some staleness, replay fan-out idempotently”—if you claim one global strongly consistent view of every mailbox, you will get a skeptical follow-up.

Bottlenecks and tradeoffs

Consistency vs latency: Cross-service strong consistency is rare. Most feeds are eventually materialized and best-effort ranked—say what you sacrifice first.

Cost vs freshness: More precompute and storage buys smoother reads; thinner mailboxes push work to read time and hurt tail latency.

Simplicity vs scale: A single relational database is a fine starting point in a classroom; at this prompt’s scale you are usually talking sharded KV or wide-column for mailboxes because the access pattern is “load a lot of IDs for one user, fast.”

Failure handling

• Ranker slow or down: Timeout; fall back to recency-only slice; feature flag off heavy models.
• Fan-out backlog: Still show read path from existing mailboxes + pull-merge; alert on queue age, shed load.
• Cache miss / stampede: TTL jitter, singleflight for hot post IDs.
• DB degraded: Circuit-break; serve stale but safe feed rather than empty 500s where product allows.

API design

Illustrative REST-style surface (GraphQL is fine if you name batching, N+1 avoidance, and field cost—feeds are exactly where naive graphs hurt).

Core resources: posts, users, me/home (collection = feed page). Version the path (/v1/) so you can deprecate fields without breaking every client.

POST   /v1/posts
GET    /v1/me/home
GET    /v1/posts/{post_id}
POST   /v1/users/{user_id}/follow
DELETE /v1/users/{user_id}/follow
POST   /v1/posts/{post_id}/reactions      # optional in scope
GET    /v1/posts/{post_id}/comments        # optional; often cursor-paged
POST   /v1/posts/{post_id}/comments

Home feed — GET /v1/me/home

Query param	Role
cursor	Opaque continuation from last response (preferred) or compound (score,post_id) if you must spell it
limit	Page size (cap server-side, e.g. ≤ 50)
ranking	top | recent (product mode; may change candidate source + ranker)
session_id	Optional, for session-scoped snapshot / experiments

Response sketch: { "items": [ Post ], "next_cursor": "...", "has_more": true }. Each Post embeds or references author, media URLs or placeholders, counts (reactions/comments), and client tokens for ranking debug only if you want to argue observability.

Errors: 401 unauthenticated; 429 with Retry-After when throttled; avoid leaking whether a blocked user exists—use generic 404/403 per product policy.

Create post — POST /v1/posts

• Headers: Idempotency-Key for safe retries (same key → same post_id, no duplicate stories).
• Body: text, link URL, media_ids[] already uploaded via separate upload URLs (multipart to object storage is common—do not put 4K video bytes in JSON).
• Success: 201 + Location: /v1/posts/{id}; body includes created_at and processing state (media_ready: pending/ready).

Follow graph

POST / DELETE on /v1/users/{id}/follow return 204 or 200 with updated counts. Graph updates are eventually visible in feed—say so if asked.

Reactions / comments (if in scope)

Prefer nested routes under the post for clarity and cache keys: POST /v1/posts/{id}/reactions with { "type": "like" }. Comments page the same way as the feed: cursor + limit, same duplicate/skip story when new comments arrive during scroll.

Cross-cutting behavior to name in the interview

• Rate limits: Per-user and per-IP on create and follow; return X-RateLimit-Remaining if you want extra credit.
• Pagination contract: Document whether next_cursor is opaque (ranker-issued) or structured; either is fine if you explain moving ranks and dupes.
• Versioning & mobile: Older app versions may send Accept-Feature or a client_version query—only if you have time; otherwise acknowledge backward-compatible field additions.

In the room: Spend one minute on idempotency for POST /v1/posts, cursor semantics for GET /v1/me/home, and why reactions are not on the critical path for feed p95—that is enough to sound like you shipped APIs, not that you memorized a table.

Production angles

These are the kinds of stories that show up in postmortems and on-call—not because the whiteboard diagram was wrong, but because queues, timeouts, and caches behave badly under real skew and real deploys. If you are junior, read them as “what can go wrong and what we measure.” If you are senior, read them as “how I’d steer the room when someone asks what breaks in production.”

Fan-out backlog while posts “succeed”

What it looks like — Traffic spikes (viral moment, live event, celebrity post). Post creation stays healthy: the API writes the row, returns 200/201, media lands in object storage. Feeds feel stale: users refresh and see yesterday’s ordering while the new post is “somewhere in the pipeline.”

Why it happens — Fan-out is asynchronous. Workers enqueue (post_id, author_id) and fan into follower mailboxes at a finite rate. When enqueue depth or per-shard backlog grows, latency to visibility grows—even though the write path succeeded.

What good teams do — Alert on queue age, consumer lag, and per-shard backlog (not just “CPU is fine”). Cap fan-out work per tick; shed load by leaning harder on read-side merge for the tail of the graph; consider priority lanes for very fresh windows vs full historical fan-out. Juniors sometimes stop at “we have a queue”; seniors name which metric goes red first and what product does while the queue drains.

Ranker deploys and thread exhaustion

What it looks like — A deploy touches the ranking service (new model, bad config, regression in feature extraction). p95/p99 for rank jumps. If the feed service blocks on ranking with a generous or missing timeout, worker threads or connection pools at the edge fill up. Unrelated routes can degrade because the fleet is wedged waiting on one dependency.

Why it hurts — Feed read is often one graph hop away from “everything feels broken”: the ranker is not a side quest; it sits on the hot path unless you explicitly isolate it.

What good teams do — Hard timeouts on rank; circuit breakers; fallback ordering (recency-only, last-known-good slice, cached scores). Kill switches and feature flags to bypass heavy models. Separate SLOs: “feed loads” vs “feed is perfectly ranked.” Seniors describe blast radius; juniors learn to never let one service hold the whole edge without an escape hatch.

Partial fan-out, multi-region, and “I see it, you don’t”

What it looks like — A celebrity post fans out to some shards or regions first; others catch up via replay, reconciliation, or pull-merge. Two coworkers in different regions argue whether the post appeared—“it’s there for me, not for you”—for minutes.

Why it happens — You almost never have one synchronous global fan-out to every mailbox. Idempotent consumers and at-least-once delivery mean duplicates are handled; ordering and visibility across regions are eventually aligned.

What good teams do — Idempotency keys on fan-out writes; dedupe in mailbox stores; observability on cross-region replication lag. Product-facing honesty: eventual visibility within N minutes under load beats pretending strong global consistency. Seniors talk SLAs for visibility and blast radius; juniors should at least not claim instant worldwide materialization.

Cache stampede on a hot post ID

What it looks like — One post goes viral. Every feed request multi-gets the same post_id. Cache entry for that key expires; thousands of requests miss together and hit the database or origin at once—thundering herd.

Why it happens — TTL expiry without jitter lines up misses. No request coalescing (singleflight) means N identical fetches become N backend hits.

What good teams do — TTL jitter; singleflight / request coalescing per key; stale-while-revalidate for read-heavy keys; sometimes local in-process caching for the hottest IDs. Seniors mention hot key observability; juniors learn that “we added Redis” does not automatically fix coordination at the moment of expiry.

---

How to use this in an interview — You do not need to recite four novellas. You do need one concrete story: pick queue lag or ranker timeout or stampede, name one metric and one mitigation, and show you understand why the user still sees a 200 on post while read quality degrades. That is the difference between a diagram and a system someone has operated.