{"title":"Design a Personalized News Feed","description":"","content":"A personalized news feed is the ranked list of posts, photos, videos, and links a user sees when they open a social app like Facebook, LinkedIn, or Twitter/X. The ranking problem looks similar to video or product recommendations on the surface, but three things make it harder: the inventory is heterogeneous, the objective is multi-dimensional, and the shelf life of most posts is measured in hours. Getting one of those three wrong breaks the feed in a different way, which is why this is one of the most instructive ML system design interview problems.\n\n---\n\n# 1. Problem Formulation\n\n### Clarifying Questions\n\nThe feed at Meta looks different from the home timeline at Twitter/X or the feed on LinkedIn. Before drawing any architecture, a candidate should lock down scope, inventory, and what counts as success.\n\n**Candidate:** \"When you say news feed, do you mean the home feed, stories, reels, or all three surfaces?\"\n\n**Interviewer:** \"Home feed only. Stories and short-form video have their own rankers. Assume our home feed includes text posts, photos, videos, link shares, and a small amount of sponsored content interleaved.\"\n\n**Candidate:** \"Is the feed purely algorithmic, or do users see a chronological option as well?\"\n\n**Interviewer:** \"Both exist, but we're designing the default algorithmic feed. Chronological is a user setting that bypasses ranking.\"\n\n**Candidate:** \"How big is the platform? DAU, posts created per day, and average feed loads per user?\"\n\n**Interviewer:** \"Around 2 billion registered users, 500 million DAU. About 20 billion new pieces of content per day across all types. An active user opens the feed roughly 10 times a day and scrolls through 50 to 100 items per session.\"\n\n**Candidate:** \"What's the candidate pool per user? Am I ranking posts only from accounts they follow, or a broader set?\"\n\n**Interviewer:** \"Broader. Followed accounts are the seed, but we also mix in posts from second-degree connections, groups the user joined, and a small exploration slice of topical content from strangers. Expect a few thousand eligible posts per user per request.\"\n\n**Candidate:** \"What's the target latency and size of a single feed response?\"\n\n**Interviewer:** \"Return 50 ranked items per request. P99 for the ranking service is 200ms end to end.\"\n\n**Candidate:** \"How do we handle ads? Are they ranked in the same model or blended in later?\"\n\n**Interviewer:** \"Ads come from a separate auction pipeline. The organic ranker returns a sorted list, and an ads-blending service inserts sponsored items at configured slots. You don't need to model the ad auction itself.\"\n\n**Candidate:** \"What's the north-star metric? Clicks, likes, session time, or something longer-horizon?\"\n\n**Interviewer:** \"We've been burned by raw engagement before. Optimizing for clicks pulls the feed toward clickbait and outrage. The north star is a weekly active retention metric combined with self-reported survey scores on how valuable users found their feed. We call that bundle 'meaningful interactions' internally.\"\n\n**Candidate:** \"What's hard-filtered before ranking? Blocked accounts, integrity-flagged content, anything else?\"\n\n**Interviewer:** \"Hard filters: blocks, mutes, reported accounts, posts flagged by integrity classifiers above a safety threshold, content the user has already seen in the last 24 hours, and content outside the user's locale when required by regional policy. Everything else is eligible for ranking.\"\n\n### Requirements\n\n**Functional Requirements:**\n\n- Return 50 ranked posts per feed request for a given user, drawing from a candidate pool of a few thousand eligible items.\n- Support heterogeneous inventory: text posts, photos, videos, link shares, and third-party embeds.\n- Enforce hard filters (blocks, mutes, integrity flags, seen-in-24h, locale) before any scoring.\n- Handle cold-start users with no follow graph using topical affinity and global trending fallbacks.\n- Handle cold-start posts by giving newly created content a bounded impression floor so the ranker has signal to learn from.\n- Allow the ads-blending service to inject sponsored content into configured slots without reshaping the organic ranking.\n- Record every impression, engagement event, and negative signal (hide, report, not interested) for retraining and monitoring.\n\n**Non-Functional Requirements:**\n\n- P99 ranking latency under 200ms.\n- Post-create to ranker-eligible under 30 seconds so new content can compete for early impressions.\n- Serve 500M DAU with a steady peak of roughly 60K ranking QPS.\n- Fairness across creator tail: a user with 100 followers should get a reasonable share of impressions when their content is relevant, not be crowded out entirely by the top 1% of creators.\n- Integrity: posts flagged above the safety threshold must never reach ranking, and the integrity filter must run before any model sees the candidate.\n- Privacy: no feature exposing the identity of another user through ranking signals (for example, a recommendation reason that would leak who reported a post).\n\n### ML Problem Framing\n\nThe feed is a pointwise multi-task ranking problem. For a given user `u` and candidate post `p`, the model predicts the probability of several engagement events, and a value model blends those predictions into a single score used for sorting.\n\nThe naive framing is a single-head CTR model: P(click | u, p). It's easy to train because every impression is labeled, but it fails in two ways. Clicks are biased toward sensational content, and a single objective cannot trade off fast engagement against longer-term signals like whether the user hides the post or marks it as not interested.\n\nA better framing uses a small set of heads, each representing a distinct user action, and a value model that combines them:\n\n- P(click | u, p, shown)\n- P(like | u, p, shown)\n- P(comment | u, p, shown)\n- P(share | u, p, shown)\n- P(long_dwell | u, p, shown), defined as at least 3 seconds visible with active scroll\n- P(hide_or_report | u, p, shown), the explicit negative signal\n\nThe blended score is a weighted sum, with the negative head subtracted. Weights are learned or hand-tuned from A/B tests that optimize the retention north star rather than raw engagement. Candidate generation is a separate stage with its own architecture; the ranker assumes it receives a few hundred to a few thousand candidates that have already cleared integrity filters.\n\n### Metrics\n\n\n| Type | Metric | Why It Matters |\n|---|---|---|\n| Offline | Per-head AUC (click, like, comment, share, long_dwell, hide) | Calibration of each head on held-out next-day impressions |\n| Offline | NDCG@10 on blended value score | How well the blend ranks real engagement events |\n| Offline | Calibration plots per head | Predicted vs observed probability per decile; drift shows up here first |\n| Online | Sessions per DAU | Do users come back more often during the experiment? |\n| Online | Meaningful interactions per user-day | Composite of long_dwell, likes, comments, shares minus hides |\n| Online | 7-day and 28-day retention | Whether the ranker is optimizing for habit, not just today's clicks |\n| Guardrail | Integrity false-positive rate | Don't fix ranking by over-filtering borderline content |\n| Guardrail | Creator-tail impression share | Fraction of impressions going to creators outside the top 1% |\n| Guardrail | Source diversity (Gini on topic/creator mix) | Detect echo chambers collapsing the feed onto a narrow set |\n| Guardrail | Negative-feedback rate (hide + report + not interested) | A slow rise here always precedes a retention drop |\n\n\n---\n\n# 2. System Architecture\n\nAt the top level, a feed request flows through four stages: candidate generation fans out across heterogeneous sources, a lightweight pre-ranker trims the pool, a heavy multi-task model scores the survivors, and a re-ranker enforces diversity, dedupe, and ads-blending rules before returning a ranked list.\n\n\n```mermaid\nflowchart LR\n REQ[Feed
Request]:::primary --> STATE[User
State Fetch]:::teal\n STATE --> CG[Candidate
Generation]:::primary\n CG --> FILT[Integrity
+ Hard
Filters]:::red\n FILT --> PRE[Pre-Ranker
~500 items]:::orange\n PRE --> RANK[Multi-Task
Ranker
~200 items]:::primary\n RANK --> RE[Re-Ranker
Diversity
+ Dedupe]:::teal\n RE --> ADS[Ads
Blending]:::orange\n ADS --> RESP[Ranked
50 Items]:::green\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nEach stage trims the candidate set by an order of magnitude while using progressively more expensive features. This chapter focuses on what's specific to feed ranking: the heterogeneity of the candidates, the blend of retrieval sources, and the re-ranking stage.\n\n### Data Flow\n\nThree loops keep the system healthy, and they run on very different cadences.\n\n\n```mermaid\nflowchart TD\n subgraph Offline[Offline Loop - Daily]\n LOGS[Impression
+ Engagement
Logs]:::primary --> JOIN[Feature +
Label Join]:::teal\n JOIN --> TRAIN[Multi-Task
Training]:::orange\n TRAIN --> CKPT[Model
Checkpoint]:::green\n end\n\n subgraph Streaming[Streaming Loop - Seconds]\n POSTS[Post Create
Stream]:::primary --> VEL[Early
Velocity
Features]:::teal\n VEL --> FEAT[Online
Feature Store]:::orange\n EVT[Engagement
Events]:::primary --> USR[Recent
User State]:::teal\n USR --> FEAT\n end\n\n subgraph Online[Online Loop - Milliseconds]\n REQ2[Request]:::primary --> FETCH[Feature
Fetch]:::teal\n FETCH --> SCORE[Score
+ Rank]:::orange\n SCORE --> RESP2[Response]:::green\n end\n\n CKPT -.served by.-> SCORE\n FEAT -.read by.-> FETCH\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe offline loop retrains the ranker on the previous day's impressions joined with labels that landed within the attribution window. The streaming loop keeps time-sensitive features fresh: a newly created post has its early-velocity features updated every few seconds as likes and comments arrive, and a user's recent-engagement vector refreshes within seconds of each action. The online loop is a straight feature-fetch-score-rank pipeline, and its budget is set by the 200ms p99 target.\n\n### Back-of-Envelope Scale\n\nBefore touching architecture details, it's worth grounding the scale with a few estimates. These numbers drive almost every design decision downstream.\n\n\n| Quantity | Estimate | Calculation |\n|---|---|---|\n| DAU | 500M | Given |\n| Feed loads per DAU per day | 10 | Given |\n| Ranking requests per day | 5B | 500M x 10 |\n| Peak ranking QPS | ~60K | 5B / 86,400 x 3 (peak factor) |\n| Candidates scored per request (ranker) | 200 | Pre-ranker output |\n| Ranker scoring ops per second at peak | 12M | 60K x 200 |\n| Eligible candidates per user per request | 3,000-5,000 | From candidate gen |\n| Posts created per day | 20B | Given |\n| Post features retained for 30 days | 600B rows | 20B x 30 |\n| Impression log volume per day | ~300B events | 5B requests x 50 items shown, deduped |\n\n\nThe 12M-per-second ranker scoring number is what drives the push toward model distillation, batched GPU inference, and aggressive caching of user-side features. The 600B post-feature rows push toward tiered storage with hot posts in Redis and long-tail posts in a columnar store.\n\n---\n\n# 3. Data\n\n### Data Sources\n\nThe feed draws from several independent data streams, each owned by a different team in most large organizations. Getting the join keys right across these sources is half the engineering effort.\n\n- **Post creation stream:** every new post arrives on a Kafka topic within milliseconds. Downstream consumers include the integrity classifier, the indexing service that writes posts to the retrieval index, and the early-velocity feature job.\n- **Engagement log:** every impression, click, like, comment, share, long-dwell event, hide, and report. This is the label source for training and the input to recent-user-state features.\n- **Social graph:** follow edges, group memberships, page subscriptions. Updated in near-real-time but consumed mostly by candidate generation, not ranking features.\n- **User profile:** slowly changing attributes like locale, declared interests, account age.\n- **Content classifiers:** topic tags, content-type labels, quality scores, integrity scores. These run asynchronously after post creation; a post is eligible to be shown once the mandatory classifiers complete, which typically takes a few seconds to a few tens of seconds.\n- **Surveys:** periodic in-product surveys asking users to rate how valuable specific posts were. Low-volume but high-signal, and essential for tuning the value model against something other than click behavior.\n\n### Feature Engineering\n\nFeed features fall into four groups: user, post, viewer-creator cross features, and context. The hardest to get right are the cross features, because they describe the relationship between a specific user and a specific post, which cannot be precomputed for all pairs.\n\n**User features** capture who is asking: their recent engagement behavior, topic-affinity embedding, active hours, device class, and session-so-far signals like how many posts they've already scrolled past without engaging.\n\n**Post features** describe the item: age in minutes, creator identity and reputation, content-type flags, topic tags, language, embedding of the text and media, quality-classifier score, integrity-classifier score, and early-velocity signals like likes-per-minute and hide-rate-per-impression.\n\n**Viewer-creator cross features** are where most of the signal lives: whether the viewer follows the creator, how many prior interactions the viewer has had with this creator, time-decayed engagement rate, and whether the viewer and creator share groups or pages.\n\n**Context features** situate the request in time and place: hour of day, day of week, device, network quality, and whether this is a cold-start session (app just opened) or a deep scroll within an existing session.\n\nCross-features between user embeddings and post embeddings are learned implicitly by the deep ranker, but a few explicit crosses via DCN-style or DeepFM-style layers tend to help on sparse signals like user-creator affinity.\n\n### Feature Table\n\n\n| Feature | Type | Source | Freshness | Description |\n|---|---|---|---|---|\n| user_embedding | Vector(128) | Batch pipeline | Daily | Learned from long-term engagement history |\n| user_topic_affinity | Vector(64) | Batch pipeline | Daily | User's preference over topic taxonomy |\n| user_recent_actions | Seq(50) | Streaming | <10s | Last 50 engagement events with metadata |\n| user_session_depth | Int | Request-time | Real-time | Posts scrolled so far in current session |\n| user_active_hours | Vector(24) | Batch pipeline | Weekly | Probability of being active per hour |\n| post_embedding | Vector(256) | Batch at create | At create | Multimodal embedding of text + media |\n| post_age_minutes | Int | Streaming | Real-time | Minutes since post creation |\n| post_creator_id | Id | Post metadata | At create | Foreign key to creator features |\n| post_topic_distribution | Vector(32) | Classifier | At create + 10s | Soft distribution over topic taxonomy |\n| post_quality_score | Float | Classifier | At create + 30s | Quality classifier output, 0 to 1 |\n| post_integrity_score | Float | Classifier | At create + 30s | Safety classifier, hard filter above threshold |\n| post_likes_per_minute | Float | Streaming | <10s | Early velocity, smoothed |\n| post_hide_rate | Float | Streaming | <60s | Hides per 1000 impressions, smoothed |\n| viewer_follows_creator | Bool | Graph service | <60s | Direct follow edge |\n| viewer_creator_interactions_30d | Int | Batch pipeline | Daily | Count of engagements with this creator |\n| viewer_creator_decayed_rate | Float | Batch pipeline | Daily | Time-decayed engagement rate |\n| context_hour_of_day | Int | Request-time | Real-time | 0 to 23 in user locale |\n| context_device_class | Categorical | Request-time | Real-time | Phone tier, tablet, web |\n\n\nThe freshness column matters more than it looks. A post's integrity score must be available before it can enter the ranker, but its velocity features update continuously after that. A viewer-creator interaction feature can lag by a day without hurting quality, because long-term affinity doesn't swing hour to hour. Knowing which features tolerate lag and which cannot is what lets the feature store keep the budget under control.\n\n---\n\n# 4. Model\n\n### Baseline Approach\n\nThe first version of every feed ranker in history has been logistic regression on hand-crafted features with a single click label. It's not glamorous, but it's honest: it sets a floor the next model has to clear, and it exposes what the feature pipeline is actually producing.\n\nA reasonable baseline looks like this:\n\n- Label: clicked or not clicked, aggregated per impression.\n- Features: a few hundred hand-crafted signals including user activity level, creator popularity, post age, viewer-creator interaction count, and simple cross-features like whether the viewer follows the creator.\n- Model: regularized logistic regression trained daily on the prior 30 days of impressions.\n- Serving: single score per candidate, sort by score.\n\nThis caps out quickly for two reasons. A click-only objective pushes the ranker toward clickbait and sensational content, because those items have the highest short-term click probability and the worst long-term effect on retention. And logistic regression cannot learn the dense interaction between a user embedding and a post embedding without extensive manual cross-featuring, so it leaves a lot of signal on the floor.\n\n### Advanced Approach\n\nThe production ranker is a multi-task deep model with a shared bottom and several task-specific heads. Variants in the literature include MMoE (Multi-gate Mixture of Experts) and PLE (Progressive Layered Extraction); the high-level architecture is similar across them.\n\n\n```mermaid\nflowchart TD\n UIN[User Features
+ Embedding]:::primary --> SHARE[Shared
Bottom MLP]:::teal\n PIN[Post Features
+ Embedding]:::primary --> SHARE\n XIN[Viewer-Creator
Cross Features]:::primary --> SHARE\n CIN[Context
Features]:::primary --> SHARE\n\n SHARE --> EXP1[Expert 1]:::orange\n SHARE --> EXP2[Expert 2]:::orange\n SHARE --> EXP3[Expert 3]:::orange\n\n EXP1 --> H1[Click
Head]:::green\n EXP1 --> H2[Like
Head]:::green\n EXP2 --> H3[Comment
Head]:::green\n EXP2 --> H4[Share
Head]:::green\n EXP3 --> H5[Long Dwell
Head]:::green\n EXP3 --> H6[Hide
Head]:::red\n\n H1 --> BLEND[Value
Model Blend]:::teal\n H2 --> BLEND\n H3 --> BLEND\n H4 --> BLEND\n H5 --> BLEND\n H6 --> BLEND\n BLEND --> SCORE[Final
Score]:::primary\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe shared bottom compresses raw features into a dense representation. Experts are small MLPs that specialize in subsets of tasks. Task-specific heads take expert outputs (optionally gated) and predict the per-head probability. The hide head is trained with the same architecture but its prediction gets subtracted from the blended score at serving time, not added.\n\nWhy this architecture works well for feeds:\n\n- The rare heads (share, hide, long-comment) benefit from parameter sharing with common heads (click, like), which have orders of magnitude more labels.\n- Gating lets the model route a video post's features through experts that are good at video-like signals, and a text post's features through different experts, without needing separate models per content type.\n- Adding a new head (for example, \"report\" or \"save for later\") is a training-pipeline change, not an architecture change.\n\nFor embedding inputs, user and post embeddings come from two-tower retrieval models, or from dedicated content-understanding models for richer text and media representations. The ranker uses these embeddings as features rather than training them from scratch.\n\n### Training\n\nTraining data comes from joining the impression log with labels that landed within the attribution window.\n\n- **Positives** per head are defined by the action: a click-positive is an impression followed by a click, a long-dwell positive is an impression with >=3 seconds active dwell, a hide-positive is an explicit hide or report.\n- **Negatives** are all impressions without the positive action within the window.\n- **Position debiasing** is applied by including rank-position as a feature at training time and zeroing it at inference, or by using inverse-propensity weighting. Without this, the ranker learns to predict that the top position always wins, which is circular.\n- **Sampling** downweights the vast oversupply of negatives and upweights rare positive classes (shares, long dwells) to keep per-head gradients balanced.\n- **Loss** is the sum of per-head binary cross-entropy losses with head-level weights. Weights are not the same as the serving blend weights; training weights are tuned to balance gradient magnitude, serving weights are tuned to maximize the retention north star.\n- **Retraining cadence** is daily, with the previous day's logs appended to the training window and the oldest day dropped. Hotfix retrains kick in when a guardrail metric moves beyond its threshold.\n\nThe value-model blend at serving time is a weighted sum:\n\n\n```python\ndef value_score(head_probs: dict, weights: dict) -> float:\n \"\"\"Blend per-head probabilities into a single ranking score.\"\"\"\n # Positive heads contribute proportionally to predicted probability.\n positive = sum(weights[h] * head_probs[h] for h in [\n \"click\", \"like\", \"comment\", \"share\", \"long_dwell\"\n ])\n # Hide is subtracted; a strong predicted hide signal outweighs other gains.\n negative = weights[\"hide\"] * head_probs[\"hide\"]\n return positive - negative\n```\n\n\nWeights are set by offline grid search on a Pareto frontier of engagement vs negative-feedback, then confirmed by A/B testing against retention. Common practice is to set the comment and share weights noticeably higher than click and like, because those actions correlate more strongly with long-term retention. The hide weight is set aggressively: a single predicted hide probability above 0.05 should usually demote a post below anything without that signal.\n\n---\n\n# 5. Serving\n\n### Inference Pipeline\n\nA feed request starts when the user opens the app or scrolls deep enough to refresh. Every request goes through the same pipeline, though different surfaces (app launch vs pull-to-refresh vs deep scroll) parameterize it differently.\n\n\n```mermaid\nflowchart LR\n REQ[Feed
Request]:::primary --> CACHE{User State
Cached?}:::teal\n CACHE -- hit --> CG[Candidate
Generation]:::primary\n CACHE -- miss --> FETCH[Fetch
User State]:::orange\n FETCH --> CG\n\n CG --> G1[Graph
Source]:::teal\n CG --> G2[Trending
Source]:::teal\n CG --> G3[Topical
ANN Source]:::teal\n\n G1 --> UNION[Union +
Dedupe]:::orange\n G2 --> UNION\n G3 --> UNION\n\n UNION --> FILT[Integrity
+ Hard Filter]:::red\n FILT --> PRE[Pre-Rank
500 to 200]:::orange\n PRE --> BATCH[Batched
Ranker GPU]:::primary\n BATCH --> RE[Diversity
Re-Rank]:::teal\n RE --> ADS[Ads
Blend]:::orange\n ADS --> OUT[Return
50 Items]:::green\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nUser state includes the user's embedding, recent-action sequence, and surface-level settings. It's cached at the edge for active users and refreshed every few seconds or on explicit invalidation. Candidate generation fans out in parallel to three sources, described in detail in the deep dives section. The integrity filter sits between candidate generation and the ranker to guarantee that no flagged content reaches a scoring model, regardless of what candidate generation produced.\n\n### Batch vs Real-Time\n\nEvery component in the pipeline lands somewhere on the spectrum from fully precomputed to computed per request. Getting the split right is how feed systems hit 200ms p99 with billion-user catalogs.\n\n\n| Component | Computed | Why |\n|---|---|---|\n| User long-term embedding | Daily batch | Changes slowly; retraining daily is enough |\n| Post embedding | Once at post create | Content doesn't change after posting |\n| User recent-action sequence | Streaming, <10s lag | Changes every scroll; request-time would miss the most recent action |\n| Post early-velocity features | Streaming, <10s lag | Changes as engagement accrues; critical for new posts |\n| Viewer-creator interaction rate | Daily batch | Long-term affinity is stable; real-time precision not worth the cost |\n| Candidate generation | Request-time | Social graph and trending both change; cached per-user for seconds at most |\n| Pre-ranker scores | Request-time | Depends on all three sources and user context |\n| Ranker scores | Request-time | Must combine freshest user and post state |\n| Diversity re-rank | Request-time | Depends on the specific 200 candidates and their topic mix |\n\n\nThe sharpest split is between daily-batch features and streaming features. A batch feature is cheap to compute once and serve many times; a streaming feature requires a continuously running job consuming from Kafka and writing to the online store. Feeds use more streaming features than most recommendation systems because the inventory itself is fresh: a post is created, accrues engagement, and decays in hours, so its features cannot be precomputed once and frozen.\n\n### Latency Budget\n\nThe 200ms p99 target has to be allocated across the pipeline, with enough slack to absorb tail latency on any single component.\n\n\n| Component | Budget | Notes |\n|---|---|---|\n| Network ingress + egress | 20ms | App to edge to ranking service |\n| User state fetch | 15ms | Edge cache hit; miss triggers reshape |\n| Candidate generation (parallel) | 30ms | Max of graph, trending, and ANN lookups |\n| Integrity + hard filter | 10ms | In-memory bloom filters plus per-candidate check |\n| Feature fetch for pre-ranker | 15ms | Online store reads, batched |\n| Pre-ranker inference | 15ms | Small MLP or GBDT, CPU |\n| Feature fetch for ranker | 20ms | Heavier feature set; cached where possible |\n| Ranker inference | 40ms | Batched across 200 candidates, GPU |\n| Diversity re-rank | 10ms | Single-threaded, deterministic |\n| Ads blending | 5ms | Insert at fixed slots |\n| Buffer | 20ms | Tail-latency headroom |\n| **Total** | **200ms** | P99 target |\n\n\nThe ranker inference budget drives the most decisions. Forty milliseconds for 200 candidates on GPU means the model has to be small enough to fit several requests per batch, or it has to be distilled from a larger teacher model. A common pattern is to train a big two-stage teacher and distill into a smaller student that fits the latency budget.\n\n---\n\n# 6. Deep Dives\n\n### 6.1 Multi-Objective Ranking and the Value Model\n\nEvery other system in this section has a cleaner objective. Video recommendations optimize watch time. Product recommendations optimize purchases. PYMK optimizes accepted connections. A news feed doesn't get to pick one. If the ranker chases clicks, users end up seeing outrage content and session length crashes a week later. If it chases long dwell, it under-weights quick reactions like likes that are genuine positive signal. If it chases pure \"meaningful interactions,\" it can under-show time-sensitive content like breaking news that a user just wants to scan.\n\nThe value model is the hinge. Its job is to combine per-head predictions into a single scalar score where weights encode a business judgment about what the feed should feel like. Setting those weights is more of a policy decision than a modeling decision, and it's tuned against long-horizon A/B results, not same-day clicks.\n\nThree strategies dominate in practice, each with distinct trade-offs.\n\n\n| Strategy | How It Works | Pros | Cons |\n|---|---|---|---|\n| Hand-tuned weights | Weights chosen by PM and ML leads, validated by A/B | Transparent, easy to reason about | Slow to adapt; prone to drift as inventory changes |\n| Learned weights | Weights optimized to maximize a chosen online metric via offline bandit or contextual RL | Adapts to shifting inventory; captures non-linear interactions | Hard to debug; can overfit to short-term signals if not regularized |\n| Pareto + A/B confirm | Offline grid search generates a Pareto frontier of engagement vs negative feedback; candidates on the frontier go to A/B tests against retention | Explicit trade-off visualization; anchors product decisions | Expensive; needs a lot of A/B bandwidth |\n\n\nCounterfactual reweighting is an important refinement in all three. Users see only the top-ranked items, so the log is biased toward the ranker's past beliefs. Inverse propensity scoring at training time corrects for this, and randomized exploration slots in production generate unbiased data for evaluating new value-model weights offline.\n\nSurveys earn their keep here. Meta has publicly discussed using in-product surveys asking users to rate individual posts as a direct signal for quality. The survey signal is low volume compared to clicks, but it anchors the value model against something closer to genuine user preference than passive engagement metrics. Without a survey signal, any value-model tuning loop slowly overfits to whatever is measurable, and the feed drifts toward whatever form of engagement is easiest to provoke.\n\n### 6.2 Candidate Generation at Feed Scale\n\nA user's social graph alone isn't enough to populate 50 quality slots. Follow graphs are sparse in the tail and dominated by inactive creators in the head; pure friend-and-follow feeds run dry within seconds of scrolling. Feed candidate generation pulls from three parallel sources, unions the results, and deduplicates before handing the pool to the pre-ranker.\n\n\n```mermaid\nflowchart LR\n USR[User
Request]:::primary --> G1[Graph Source
Follows + 2nd Degree]:::teal\n USR --> G2[Trending Source
Viral-by-Affinity]:::orange\n USR --> G3[Topical ANN
User Embedding]:::green\n\n G1 --> POOL[Candidate Pool
3000-5000 items]:::primary\n G2 --> POOL\n G3 --> POOL\n\n POOL --> DEDUP[Dedupe
+ Quota]:::teal\n DEDUP --> OUT[To Integrity
Filter]:::orange\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe graph source walks direct follows, groups, and second-degree connections, returning recent posts sorted by a cheap recency-weighted engagement score. The trending source retrieves posts with high velocity restricted to topics or creator clusters the user has engaged with before. The topical ANN source performs an approximate nearest-neighbor lookup against post embeddings using the user's topic-affinity embedding as the query, pulling in content from accounts the user doesn't follow but is likely to engage with.\n\n\n| Source | Strength | Weakness | Typical Quota |\n|---|---|---|---|\n| Social graph | Highest precision for engaged users, natural explanation (\"your friend posted\") | Dries up for low-connection users; biased toward head accounts | 40-60% |\n| Trending-by-affinity | Brings in fresh, viral content within user's interest space | Risk of same-content-twice if dedupe is loose | 20-30% |\n| Topical ANN | Exploration beyond the follow graph; critical for cold-start users | Lower precision; can surface low-quality content if not filtered | 10-30% |\n\n\nThe quotas are per-request targets and shift based on user state. A user with 5 follows gets almost all candidates from topical ANN. A user with 500 follows gets most from the graph. Cold-start post handling lives mainly in the trending source: a new post from a creator the user follows enters the graph source immediately, but posts from creators the user doesn't follow need to accumulate enough early velocity in the trending-by-affinity job before they become eligible for that user's feed. Giving new posts a small impression floor, even without signal, is how the system avoids an absorbing-state problem where new content can never accumulate enough data to compete.\n\nDeduplication operates on two levels: the same post ID cannot appear twice, and near-duplicate content from different IDs (same link share, same reposted video) is collapsed to a single candidate based on content fingerprinting. The dedupe step sits before the pre-ranker so the expensive stages don't waste cycles on redundant items.\n\n### 6.3 Diversity, Filter Bubbles, and Fairness\n\nIf a ranker optimizes pure predicted engagement, every user's feed collapses onto a narrow set of creators and topics. The top 200 candidates after ranking might all be from the same five creators, all on the same topic, because those are the highest-scoring items this user will see today. That's bad for users (monotony), bad for creators (winner-take-all), and bad for the platform (retention drops when the feed feels repetitive).\n\nRe-ranking applies diversity, fairness, and dedupe constraints after the ranker has scored the candidate set. Several layers run in sequence, each enforcing a different kind of constraint.\n\n\n```mermaid\nflowchart LR\n IN[200 Scored
Candidates]:::primary --> DEDUP[Near-Duplicate
Collapse]:::teal\n DEDUP --> CAP[Source +
Topic Caps]:::orange\n CAP --> MMR[Greedy MMR
Diversity Pick]:::primary\n MMR --> TAIL[Creator-Tail
Boost]:::teal\n TAIL --> EXPL[Exploration
Injection]:::orange\n EXPL --> OUT[Final 50
Ordered Items]:::green\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe order matters. Near-duplicate collapse runs first so the greedy picker never compares two almost-identical items. Source and topic caps filter out candidates that would violate constraints before the picker sees them. The MMR layer does the actual diversity-aware selection. Creator-tail boost and exploration injection apply late, after the bulk ranking is done, so they don't distort the relative ordering of the main selections.\n\nA common algorithm for the MMR layer is a greedy selection that balances relevance against redundancy.\n\n\n```python\ndef diversity_rerank(candidates, k=50, lambda_div=0.3):\n \"\"\"Greedy re-rank balancing ranker score and topical diversity.\"\"\"\n selected = []\n remaining = list(candidates)\n while remaining and len(selected) < k:\n best = None\n best_score = -float(\"inf\")\n for c in remaining:\n # Penalize candidates too similar to already-selected set.\n max_sim = max(\n (cosine(c.topic_vec, s.topic_vec) for s in selected),\n default=0.0,\n )\n score = (1 - lambda_div) * c.value_score - lambda_div * max_sim\n if score > best_score:\n best, best_score = c, score\n selected.append(best)\n remaining.remove(best)\n return selected\n```\n\n\nThe lambda controls how much diversity is worth in units of value-score. Setting lambda too high pushes out high-quality content in favor of variety; too low and the feed collapses. The right setting is typically small, around 0.1 to 0.3, and itself a hyperparameter subject to A/B testing.\n\nBeyond MMR, several practical constraints layer on top.\n\n\n| Technique | What It Does | When It Kicks In |\n|---|---|---|\n| Source caps | Limit N posts from any single creator per feed window | Always; typical cap is 2 or 3 per session |\n| Topic caps | Limit the fraction of slots dedicated to any single topic | When topic mix across top 50 exceeds a threshold |\n| Creator-tail boost | Small additive bonus to candidates from creators outside the top 1% by impressions | Always; magnitude tuned against fairness metrics |\n| Exploration injection | Random slot insertion of candidates from under-explored topics | At configured frequency, typically 1 in 20 slots |\n| Echo-chamber audit | Offline scan for users whose feed exposure has collapsed below a diversity threshold | Batch, daily; triggers reset of exploration injection rate |\n\n\nThe creator-tail boost deserves special attention. Without it, the top 0.1% of creators by follower count win almost every scoring comparison because they have more engagement data, better velocity features, and higher-quality content on average. Giving tail creators a small score bonus keeps the feed's creator distribution from collapsing onto the head, which matters for the platform's long-term content supply, not just fairness.\n\n### 6.4 Freshness and Real-Time Signals\n\nThe median post has a useful life of a few hours. Some posts, like breaking news, have a useful life of minutes. Unlike video recommendations or product recommendations, where the catalog turns over slowly and content stays relevant for weeks, feed ranking is constantly racing against the clock.\n\nThree design decisions follow from this.\n\nFirst, post-create to ranker-eligible must be fast. The pipeline from post creation through integrity classification, indexing, and feature population runs on a streaming backbone with a 30-second budget. Anything slower and trending content misses its window. This is why quality and integrity classifiers have to be fast; they cannot afford minute-scale batch cadences.\n\nSecond, early-velocity features dominate early-life ranking. A post that's two minutes old has no viewer-creator interaction history to pull from, no long-term velocity, and no established engagement rate. What it has is likes-per-minute and hide-rate-per-impression over its first few hundred impressions, and those are the features that tell the ranker whether this specific post is resonating. Early-velocity features update every few seconds on a streaming job keyed by post ID.\n\n\n```mermaid\nflowchart LR\n POST[Post
Created]:::primary --> INT[Integrity
Score]:::red\n POST --> IDX[Retrieval
Index]:::teal\n POST --> VEL[Velocity
Tracker]:::orange\n\n INT -.gates.-> IDX\n IDX --> ELIG[Ranker
Eligible]:::green\n\n IMP[Impression
Event]:::primary --> VEL\n ENG[Engagement
Event]:::primary --> VEL\n VEL --> STORE[Online
Feature Store]:::teal\n STORE -.read by.-> ELIG\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThird, the scoring function applies an explicit recency decay. The ranker learns to predict the engagement probability from features, but those features include post age. In practice, a small multiplicative decay on the final score based on post age is still applied to ensure that two posts with similar predicted engagement don't crowd out freshness. A typical decay halves a post's effective score every 6 to 12 hours.\n\nSpiky posts create a specific headache. A post that goes viral in its first hour accumulates velocity features so strong that the ranker predicts very high engagement for every viewer, which is mostly correct but has two failure modes. One, the post dominates the feed for hours until the velocity signal decays, pushing out everything else. Two, the velocity feature is easy to manipulate by coordinated early engagement, so a small cluster of accounts can inflate a post's early-life score. The mitigations are source caps in re-ranking (a single post can only appear once per user per day) and trust-weighted velocity (engagements from historically reliable accounts count more than engagements from brand-new accounts).\n\nModel artifacts themselves have a freshness question. The ranker is retrained daily, but the world can shift faster than that during events like elections or natural disasters. Some platforms keep a small set of fast-retraining shadow models that can be swapped in if the live model's calibration degrades beyond a threshold. This is the difference between a ranker that's fresh and a ranker that's robust: the features can be seconds old, but if the model's weights are stale against a new distribution, the feature freshness doesn't help.\n\n---\n\n# 7. Evaluation and Iteration\n\n### Offline Evaluation\n\nBefore any new model or value-model weight touches production, it gets scored on held-out impressions from the previous day. Per-head AUC measures whether each head is well-calibrated; NDCG@10 on the blended score measures whether the new configuration would rank real engagement events higher than the live model would.\n\nTwo specific offline checks catch the most common failure modes. Calibration plots per head reveal when a head is systematically over- or under-predicting at certain deciles, which is usually the first sign of a feature-pipeline bug or distribution shift. And replay scoring, where the new ranker scores the same candidate pools the live ranker saw, computes the correlation between the two rankings. A correlation below 0.7 against the live model usually signals something more surgical than an experiment should change.\n\n### Online Evaluation\n\nEvery candidate model goes through a staged rollout: shadow mode where it scores but doesn't serve, a 1% A/B where it serves a small slice, then progressively larger slices if metrics hold.\n\nThe interesting thing about feed A/B tests is that short-horizon metrics can lie. A new ranker that cranks up the click weight will show better clicks in a one-week A/B and worse retention in a four-week holdout. The standard response is to maintain long holdouts: a 1% slice of users kept on the previous model for a quarter, with retention and survey scores measured against the treatment group. Compounding retention effects only show up in weeks, not days, so long holdouts are not optional.\n\nGuardrail metrics run alongside the primary metrics on every test. The integrity false-positive rate cannot rise. Creator-tail impression share cannot collapse. Negative-feedback rate (hides, reports, not-interested clicks) cannot increase. If any guardrail moves beyond its threshold, the test is paused regardless of what the primary metric says.\n\n### Monitoring\n\nOnce a model is live, monitoring falls into four categories: feature drift, model calibration drift, guardrail metrics, and segment-level health.\n\n\n```mermaid\nflowchart LR\n SERVE[Live Ranker
Serving]:::primary --> LOG[Serving Logs
+ Predictions]:::teal\n LOG --> FDRIFT[Feature
Drift PSI]:::orange\n LOG --> CAL[Per-Head
Calibration]:::orange\n LOG --> GUARD[Guardrail
Metrics]:::red\n LOG --> SEG[Per-Segment
NDCG]:::orange\n\n FDRIFT --> ALERT{Any Threshold
Breached?}:::teal\n CAL --> ALERT\n GUARD --> ALERT\n SEG --> ALERT\n\n ALERT -- yes --> INVEST[Page Oncall
+ Auto-Pause
Experiments]:::red\n ALERT -- no --> OK[Normal
Operation]:::green\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nServing logs feed every monitor in parallel. Each monitor has its own threshold and its own response: a feature PSI spike pages the data team, a per-head calibration drift pages the ML team, a guardrail breach auto-pauses any active experiments on the affected surface.\n\n\n| Monitor | What It Catches | Alert Threshold |\n|---|---|---|\n| Feature distribution (per feature) | Upstream pipeline failures, shifts during news events | 5% PSI change day-over-day |\n| Head calibration (predicted vs observed) | Model degradation under distribution shift | Miscalibration >10% in any decile |\n| Creator-tail impression share | Re-ranking weight drift | >5 percentage point drop week-over-week |\n| Integrity false-positive rate | Over-filtering breaking feed quality | >0.5% FP on sampled audits |\n| Per-segment NDCG (new users, low-activity users, power users) | Ranker regressions that hide in the average | >3% drop for any segment week-over-week |\n| Negative-feedback rate | Slow creep toward outrage content | >10% week-over-week rise |\n\n\nThe trickiest monitor is per-segment health. An overall engagement metric can look flat while new users are getting a progressively worse experience, because power users generate most of the engagement volume and drown out new-user signal. Splitting by segment and alerting on segment-level regressions is how long-term retention gets protected against average-case drift.\n\nFeature drift alerts are the most common false positive. Topic distributions shift during real-world events (elections, sports seasons, natural disasters), and the ranker has to absorb that shift without triggering a rollback. The standard pattern is to alert on drift but gate rollback on calibration or guardrail metrics, so a natural distribution shift doesn't unnecessarily revert a healthy model.\n\n---\n\n# Interview Questions\n\n**Q1: Why is a multi-task ranker the right choice for a feed, and what would go wrong with a single-head CTR model?**\n\nA single-head CTR model optimizes for one signal that correlates with short-term clicks but not long-term value. Clickbait has high CTR, so the feed drifts toward outrage and sensational content within weeks. Users who find their feed progressively worse churn quietly, which shows up as a retention decline months later, long after the ranker change that caused it. A multi-task model predicts click, like, comment, share, long-dwell, and hide probabilities jointly, and a value model blends them with weights tuned against retention. This lets the system make explicit trade-offs like \"a predicted hide outweighs a predicted click\" rather than pretending a single number captures everything.\n\n**Q2: How would you decide the weights in the value model that blends per-head predictions?**\n\nThree approaches work in practice and each has trade-offs. Hand-tuned weights are transparent and stable but slow to adapt as the content mix shifts. Learned weights, optimized via contextual bandits or RL, adapt faster but are hard to debug and can overfit to easy-to-measure signals. The most common approach in large teams is to generate a Pareto frontier offline over engagement vs negative-feedback, pick a few promising points on the frontier, and A/B test them against retention and survey-based quality metrics. Whichever approach you pick, counterfactual reweighting on the training logs and a small randomized exploration slot in production are essential, because the ranker's own past behavior biases every metric the new weights are scored on.\n\n**Q3: Why does feed ranking need streaming features more than most recommendation systems?**\n\nThe useful life of a feed post is measured in hours. A post created five minutes ago has no viewer-creator interaction history, no established engagement rate, and no long-term velocity signal. What it has is a few minutes of early engagement data, and the ranker's ability to score it well depends on having that data available in under 10 seconds. In contrast, a video or product in a catalog has a shelf life of weeks or months, so daily-batch features capture most of the signal. Feeds can't afford that cadence because the window between a post being created and the ranker deciding whether to show it is often shorter than a batch job's schedule.\n\n**Q4: How do you prevent a feed ranker from collapsing onto a small set of creators, and what are the trade-offs of your approach?**\n\nThe core issue is that pure engagement optimization is a winner-take-all process. Top creators have more data, better velocity signals, and higher average engagement, so they win almost every scoring comparison. Diversity re-ranking with a greedy MMR-style algorithm penalizes candidates too similar to what's already selected in the feed, and source caps limit how many posts any single creator can appear in per session. A creator-tail boost adds a small score bonus to candidates from creators outside the top 1% by impressions. The trade-off is that diversity costs short-term engagement: an MMR lambda of 0.3 might drop same-day engagement by 1-2% while increasing retention measurably over weeks. The balance is set by A/B tests on long-horizon metrics, not same-day clicks.\n\n**Q5: A new post goes viral in its first hour. Its velocity features predict extremely high engagement for every viewer. What can go wrong, and how do you mitigate it?**\n\nTwo failure modes show up. The post dominates feeds for hours because its predicted score beats almost everything else, pushing out content variety and creating a monotonous experience. And the velocity features are easy to manipulate: a small cluster of accounts engaging immediately after post creation can inflate the early-life score, which is the basis of many coordinated-inauthentic-behavior campaigns. Mitigations include per-user-per-day source caps so a single post cannot appear more than once in a user's feed per session, trust-weighted velocity where engagements from accounts with a long history count more than engagements from brand-new accounts, and recency decay that halves effective score every 6-12 hours regardless of predicted engagement. These don't eliminate virality, they bound its reach.\n\n---\n\n# Summary\n\n- A personalized news feed is a pointwise multi-task ranking problem over heterogeneous, short-lived inventory, and multi-objective optimization is what makes it distinct from video or product recommendations.\n- The ranker predicts several engagement probabilities (click, like, comment, share, long-dwell, hide) and a value model blends them with weights tuned against retention, not same-day clicks.\n- Candidate generation runs in parallel across three sources (social graph, trending-by-affinity, topical ANN) because no single source covers both warm and cold-start users well.\n- Integrity and hard filters run before the ranker touches any candidate, not after, because letting flagged content enter the scoring stage is a safety hazard regardless of final ranking.\n- Streaming features matter more for feeds than for most recommendation systems because post shelf life is hours; post-create to ranker-eligible under 30 seconds is a hard requirement.\n- Diversity and fairness are enforced at re-rank time via MMR, source caps, creator-tail boosts, and exploration injection; without these, the feed collapses onto the top 0.1% of creators.\n- Offline AUC and NDCG evaluate the ranker; long online holdouts of a quarter or more catch the retention effects of a ranker change that a short A/B cannot see.\n- Monitoring splits by user segment because average metrics hide per-segment regressions, especially for new and low-activity users.\n\nThe next chapter tackles ad click prediction, which shares many patterns with feed ranking but has its own specifics: extreme sparsity, tight calibration requirements, and an auction on the other side that turns predicted CTR into a bid.","pageType":"ml-system-design"}

Design a Personalized News Feed

Ashish Pratap Singh

Get Premium