M2 Design Facebook News Feed

Design Facebook News Feed

Welcome everyone, today we will design a Facebook style News Feed and walk through multi source ranking, privacy filtering, aggregation, and ads interleaving under tight latency and experiments.

From Instagram Feed to Facebook News Feed: what got harder?

Dr. Wei: Before we design the Facebook News Feed, let’s anchor ourselves in a simpler mental model: an Instagram style feed where most posts come from accounts you follow, and the system mainly focuses on ranking and freshness.

Dr. Wei: Look at this first bullet: it’s describing that Instagram-style setup, mostly one source of content, ranked into a single timeline.

Sam: So the candidate pool is basically accounts I follow, and the main knob is ranking them by relevance and freshness in one list.

Dr. Wei: Now the second bullet is the shift: Facebook pulls from friends, groups, pages, reshared posts, and ads, and it adds privacy and aggregation constraints on top of ranking.

Sam: That makes it feel like multiple feeds smashed together, plus rules that can remove items after the fact, which sounds like it complicates ordering and correctness.

Dr. Wei: Exactly, and that is our driving question: when you go from the first bullet to the second, what got harder and why, especially around multi-source composition, privacy, aggregation, and mixing organic content with ads.

Meta interview pacing: S‑E‑D‑E as a feed design checklist

Dr. Wei: This slide is just a title at first, so I want you to focus on the idea: we need a pacing tool to keep a feed design interview structured and time-boxed.

Sam: I tend to get deep into ranking details early. Is S E D E meant to keep me from over-optimizing one part before I define the problem?

Dr. Wei: Yes. First, we reveal S: Stage. That means clarify the goal, the user experience, and the constraints before you propose architecture.

Dr. Wei: Second, we reveal E: Explore. This is where you list plausible choices like push versus pull, precompute versus on-demand, and different ranking approaches.

Dr. Wei: Third, we reveal D and the final E: Decide, then Evaluate. Decide means pick one approach and state why, and evaluate means define what you would measure, like latency, freshness, and correctness, plus what you would do when something degrades.

Sam: So in practice I should keep looping: frame, compare, commit, and then sanity-check with metrics and failure modes, instead of treating the design like one long monologue.

Requirements and scale: numbers that force the architecture

Dr. Wei: This slide is about turning scale into architecture, but at the title-only view, hold one thought: if you cannot estimate load and latency, you cannot justify caching, precompute, or service budgets.

Sam: For calibration, should I assume something like billions of users and then back into queries per second, or do you want me to start with a single region and scale up?

Dr. Wei: Start broad and then localize. First number: daily active users times sessions per day gives total feed requests per day, and dividing by seconds in a day gives average queries per second.

Dr. Wei: Second number: candidate pool. Friends and follows times posting rate tells you how many new stories could be eligible, which pushes you toward pruning and multi-stage ranking rather than scoring everything.

Dr. Wei: Third number: latency target. For a feed render, you pick a tail latency budget, like p ninety nine under a few hundred milliseconds end to end, and that forces per-service budgets and timeouts.

Sam: And if my rough math is off by ten times, the architecture changes: either I need more aggressive candidate pruning and caching, or I accept lower freshness or lower ranking quality to hit the tail latency.

$A-P-I$ and data model: what is a story we can rank?

Dr. Wei: Before we can rank anything in a news feed, we have to agree on what a story is and what the feed A P I guarantees. If we skip this contract, later choices around privacy, updates, and ads become ambiguous.

Sam: When you say feed A P I guarantees, do you want me to explicitly state what is stable across pages, like ordering and cursors, and what is allowed to change, like reaction counts?

Dr. Wei: Start with this Story schema bullet. This story id is the stable identifier we paginate and log. This actor id is who performed the action, and this object id is what the action is about, like a post or a photo.

Sam: And the type and timestamp tell me what happened and when, while the privacy policy id decides whether I can see it, and the aggregation key is how I group related actions into one story card.

Dr. Wei: Now look at the ordering invariant bullet. Sorting by timestamp descending gives freshness, and sorting by story id descending as a tie-breaker makes the order deterministic when timestamps match.

Dr. Wei: Next, the pagination invariant bullet. This cursor encodes the last seen timestamp and story id, and the next page must return strictly older stories, or if timestamps tie, only those with a smaller story id, so we never duplicate or skip due to unstable sorting.

Dr. Wei: Finally, the visibility invariant bullet is the safety rule: apply privacy filtering before ranking and before producing the page result, and define the cursor over the final filtered, deterministically ordered sequence. That way a restricted story never becomes a top ranked result, and the cursor does not advance past items the viewer cannot see.

High-level pipeline: generators $\rightarrow$ composer $\rightarrow$ ranker $\rightarrow$ serve

Dr. Wei: Today we will build an intuition for the News Feed request pipeline, from generating options to selecting what a person actually sees. The key idea is that we separate concerns into stages with clear contracts, so we can move fast without breaking the end to end experience.

Sam: If I were explaining this in an interview, should I emphasize the contracts between stages, like what goes into the request and what comes out, before I talk about the internal implementation details?

Dr. Wei: First reveal is the four core stages and what each one is responsible for. Candidate generators fetch a broad set, the composer applies product rules and builds the ranking request, the ranker scores and orders, and the serve layer returns the feed and logs what happened.

Sam: So the composer is not the model itself. It is more like the traffic cop that merges candidates, applies rules, and decides what gets sent to ranking.

Dr. Wei: Second reveal adds cross cutting concerns around that core flow. Privacy filtering, ads, and experiment guardrails can run alongside the main path, but we still want the same clear contracts and a single end to end latency budget that every stage has to respect.

Sam: And those numbers imply timeouts and fallbacks. Like if the ranker is slow, we might return a cached feed, or a lighter ranking, instead of blocking the whole request.

Dr. Wei: Exactly, and the point of calling these out separately is that they are guardrails, not the core job of ranking. They have to be reliable and fast, so they can protect the result without blowing the overall latency budget.

Multi-source merging: $K$ ranked lists into one feed

Dr. Wei: When a person opens News Feed, we usually are not pulling posts from just one place. We are combining several ranked streams, like friends, groups, pages, and ads, into a single scroll. The challenge is to merge those ranked lists into one feed that still feels relevant, fair, and diverse.

Dr. Wei: Focus on the headline phrase K ranked lists into one feed. K just means multiple sources, and the design question is: do we merge by a single comparable score, or do we enforce mixing rules like quotas and spacing?

Dr. Wei: Let’s do a tiny worked example. Suppose we have three sources, each already ranked by its own model score. Friends: F1 score 0.90, F2 score 0.70. Groups: G1 score 0.95, G2 score 0.60. Pages: P1 score 0.80, P2 score 0.65. Sam, predict the top five items if we do a pure score-based merge: always take the current highest score among the list heads.

Sam: Start with the largest head item. So first G1 at 0.95, then F1 at 0.90, then P1 at 0.80. After that, heads are F2 at 0.70, P2 at 0.65, and G2 at 0.60, so next is F2 then P2. Top five: G1, F1, P1, F2, P2.

Dr. Wei: Yes. Notice what that choice implies: a score-first merge includes P2 at 0.65 and leaves out G2 at 0.60 from the top five. That’s the relevance-first outcome: we keep the higher-scoring item even if it means less source variety near the top.

Dr. Wei: Now reveal the second merging idea: constraints. Predict the top five if we use a quota style policy to guarantee diversity, like a repeating pattern: one Friends, then one Groups, then one Pages, and repeat, taking the next item from that source even if another source has a higher score waiting.

Sam: Pattern is Friends then Groups then Pages then Friends then Groups. So that would be F1, then G1, then P1, then F2, then G2.

Dr. Wei: Right, and here’s the explicit swap: the quota forces G2 at 0.60 into the fifth slot, displacing P2 at 0.65, even though P2 is more relevant by score. That’s the diversity-first consequence: you gain source balance, but you can give up some immediate relevance at the margin.

Ranking: from EdgeRank to two-pass ML

Dr. Wei: Modern feed ranking is usually two-stage: a fast, lightweight scorer narrows the field, and then a heavier learned model does the final ordering.

Sam: So it's a funnel: cheap scoring first, then the expensive model on a smaller set.

Dr. Wei: Now look at the equation labeled as the legacy first-pass heuristic. Read it left to right: this score is affinity between the viewer and the actor, times a weight for the content type, times a time-decay term based on how old it is.

Sam: Affinity is basically, do I tend to engage with that person, and decay just downranks older items, right?

Dr. Wei: Then connect that to the first bullet: this light ranker, often a fast heuristic or small model, selects a few thousand candidates so we can afford to do more work later.

Sam: Got it. The first pass is about speed and recall, not perfect ordering.

Dr. Wei: And the second bullet is the payoff: this heavy ranker reranks only a few hundred with richer features under tight latency, which is how you get better relevance without scoring millions of stories online.

Sam: So the two bullets explain why the equation is not the whole story. The equation is a simple first filter, and the heavy model is where you spend feature cost, while keeping the end to end budget under control.

Privacy-aware feed generation: correctness first, then speed

Dr. Wei: Before we worry about ranking, caching, or latency, we have to get one thing right: what a person is allowed to see.

Sam: Isn't privacy just a filter we apply at the end after we collect all the candidate stories?

Dr. Wei: Use the slide title as the rule: correctness first, then speed. That means visibility checks must happen before ranking, before caching results, and before logging impressions, because any one of those can leak content if you filter too late.

Sam: So even if I never show the story on screen, I could leak it by putting it in a cache key, a debug log, a prefetch response, or an analytics pipeline if the filter is at the end.

Dr. Wei: Exactly. And once correctness is enforced, then we optimize: we precompute audience sets, cache privacy decisions, and design data fetches so we avoid repeatedly evaluating the same privacy policy for the same viewer and story.

Story aggregation: reduce noise without hiding meaning

Dr. Wei: When people open a feed, they do not want to scroll through ten tiny updates that all mean the same thing. A key idea is story aggregation: combine related activity so the feed feels calmer and easier to read, while still preserving what matters to the viewer.

Sam: Is the main objective here user experience, or are we also doing aggregation to cut down the amount of ranking and rendering work per request?

Dr. Wei: Use the title to anchor the goal: reduce noise without hiding meaning. Aggregation is the mechanism that lets one scroll item represent multiple related actions.

Dr. Wei: Think of it as turning many low level events into one higher level story. Instead of showing every single like, comment, and follow as separate entries, we group them into a single unit the person can understand at a glance, and we rank that unit as a whole.

Sam: So the aggregation key from the story schema is what makes this possible: it tells us which events can be collapsed into one story card, and then we rank the card, not the raw events.

Dr. Wei: And the tradeoff is in the title. If we aggregate too aggressively, we hide important context, like who did what. If we aggregate too little, we keep noise. A good aggregation keeps the who and what, preserves the strongest signal, and offers expand for details.

Ads integration: interleave sponsored with organic at runtime

Dr. Wei: When we build a News Feed, we are not only ranking organic posts. We also have sponsored content that must be shown in a way that is useful for the viewer and reliable for the business. The key idea is to combine these streams at runtime, rather than hard-coding ads into the organic ranking.

Sam: In an interview, is it enough to say we interleave two ranked lists, or do you expect me to explain who owns the final decision, the feed service or the ads service?

Dr. Wei: Anchor on the title phrase interleave at runtime. That means we have an organic ranked list and a sponsored ranked list, and we decide positions during serving, not during offline model training.

Dr. Wei: This is why we treat ads as another candidate list but with delivery constraints. For example, pacing means avoid bursts, and commitments mean the system must hit impression goals over a time window.

Sam: So at an eligible slot, I cannot just pick the highest ad score. I also have to check spacing, max density, and whether an advertiser is ahead or behind on delivery.

Dr. Wei: Exactly. The runtime interleaving problem is: given these two ranked lists, apply guardrails like maximum ad density and minimum spacing, then choose the best available ad that keeps delivery smooth and keeps user experience acceptable.

Real-time updates: comments and reactions on stories already served

Dr. Wei: Let’s talk about a common News Feed moment: you are reading a story, and while it sits on your screen, it keeps changing as new likes, reactions, and comments arrive.

Sam: Is the main mechanism here push updates to the client, or do we still rely on periodic refresh and only push the most critical events?

Dr. Wei: Anchor on the title: these are updates on stories already served. The product requirement is that counts and recent comments refresh, but the item should not jump to a new position every time an event arrives.

Sam: So we need two kinds of freshness: content freshness for what stories appear, and interaction freshness for the story details, without reshuffling the whole feed.

Dr. Wei: Exactly. For interaction freshness, we publish events like new comment, reaction change, and count deltas, and the client subscribes so it can patch the story in place. Ordering stays stable because ranking decisions for the page are not recomputed on every small interaction.

Dr. Wei: So the design question on this slide is: which events do we push, how do clients subscribe, and what do we do if the real time channel drops, so the story still updates eventually without breaking consistency.

Failure modes and IC-level tradeoffs: what interviewers probe

Dr. Wei: In a News Feed design interview, strong answers do not stop at the happy path. Interviewers listen for how you think when things break, what you choose to protect first, and how you justify tradeoffs under real-world constraints.

Sam: When you say failure modes, should I structure it by pipeline stage, like generators, composer, ranker, serve, or by dependency type, like storage, cache, and network?

Dr. Wei: Use the slide title as a checklist: failure modes and tradeoffs. Failure modes include data delays, cache misses, ranking service overload, and partial outages, and each one needs a defined fallback behavior.

Sam: In terms of priority, I would protect correctness and safety first, then availability, and only then relevance. Like I would rather serve a slightly stale but safe feed than risk privacy or policy violations.

Dr. Wei: Good. Now the tradeoffs part of the title is where interviewers probe your judgment: latency versus relevance, freshness versus consistency, cost versus quality, and safety versus engagement. For each tradeoff, name a metric and a lever, like tightening timeouts, switching to a lighter ranker, or falling back to cached candidates.

Dr. Wei: That is what an individual contributor level answer sounds like: concrete degradation plans, measurable goals, and clear reasoning for what you sacrifice when the system is under stress.

Exit ticket: do the numbers, then justify the policy

Dr. Wei: For the exit ticket, you will do two things: first, a quick quantitative estimate; second, a policy decision that you can justify from a product point of view.

Sam: To make it concrete, would a good estimate be something like queries per second and a latency budget per stage, or do you want something like how many candidates we can afford to score online?

Dr. Wei: Anchor on the title phrase do the numbers. That means write down assumptions, compute a load or latency figure, and keep units consistent so the result is interpretable.

Sam: And the justify the policy part is where I explain what guardrail I choose, like max ad density or a privacy-first fallback, and tie it back to my estimate and the user experience tradeoff.

Dr. Wei: Exactly. Treat it like you are on a News Feed team: put a number on the situation, then argue for a decision that balances user experience, creator impact, and platform goals.

Dr. Wei: Your work will be graded on clarity, not on having the single perfect answer: show your assumptions, keep units consistent, and make sure your policy justification follows logically from your estimate.

Thank you for watching!

Thanks for watching. Subscribe and share if you found this useful—see you next time!