Why the seemingly simple question “what should we show this person next?” is one of the hardest problems in modern software engineering.

Open TikTok, Instagram, or YouTube and you land on a screen with no folders, no search bar you’re forced to use, and no explicit instructions from you about what to show. Yet within a fraction of a second, the app has already decided — out of a catalogue of literally billions of videos, posts, and photos — which handful to put in front of your eyes first. That decision, repeated billions of times a day across a billion different people, is the job of a “For You” algorithmic feed.

This is one of the hardest problems in modern software engineering, not because any single piece of it is exotic, but because it sits at the intersection of three disciplines that don’t naturally get along: large-scale distributed systems (the plumbing has to move and rank data for a billion people, fast), machine learning (the ranking itself is a prediction problem), and product strategy (freshness, relevance, and diversity actively pull against each other, and the “right” answer is a business judgement, not just a technical one).

1.1 A Short History

Before drawing a single box, lock down exactly what the system must do — and just as importantly, why every “obvious” naive answer fails.

Let’s define the problem precisely before designing anything.

Design a system that, for any of a billion users, at any moment, selects and orders a small set of items (posts, videos, photos) from a catalogue of billions, such that the result is fresh, relevant to that specific person, and diverse enough to avoid staleness or a filter bubble — all within a latency budget of well under 200 milliseconds.— The precise problem statement

2.1 Why Naive Approaches Fail

The real system has to hold three forces in tension simultaneously:

2.2 Functional and Non-Functional Requirements

Before drawing a single box on a whiteboard, a disciplined design session should separate what the system must do from the qualities it must have. Interviewers reward candidates who make this split explicit and negotiate scope rather than silently assuming it.

The seven mental models you’ll reach for repeatedly — the funnel, relevance signals, freshness decay, diversity, exploration, ANN search, and CAP as it applies to a feed.

3.1 The Funnel: Candidate Generation → Ranking → Re-ranking

No system scores every item in the catalogue for every user — that would mean scoring billions of items per request, which is computationally impossible within a 150ms budget. Instead, every production feed system uses a funnel that narrows the candidate set at each stage, applying progressively more expensive (and more accurate) models as the set shrinks.

3.2 Relevance Signals

3.3 Freshness

Freshness isn’t just “newest first” — it’s a decay function applied to a content’s relevance score, plus a reserved “exploration budget” that guarantees a slice of the feed is allocated to recent, low-history content regardless of its predicted score. Common formulations use exponential time decay: score_adjusted = score_relevance × e^(−λ × age_hours), where λ is tuned per content type (news decays in hours, evergreen tutorials decay in weeks).

3.4 Diversity

Diversity is usually implemented as a constrained re-ranking problem: maximise total relevance of the selected slate subject to constraints like “no more than 2 items from the same creator in any 10-item window” or “at least 3 distinct topic categories in the top 10.” A common mathematical framework is submodular optimisation (e.g., Maximal Marginal Relevance), which rewards items that are relevant and different from what’s already been selected.

3.5 Exploration vs Exploitation

This is the classic multi-armed bandit problem borrowed from reinforcement learning. Exploitation means showing content the model is confident you’ll like (based on history). Exploration means occasionally showing uncertain content to (a) learn more about your preferences and (b) give new/cold-start content a chance to prove itself. Techniques include epsilon-greedy (show a random item X% of the time), Thompson Sampling, and Upper Confidence Bound (UCB) methods that favour items with high uncertainty as well as high predicted score.

3.6 How Approximate Nearest Neighbour Search Actually Works

Since candidate generation leans so heavily on embedding similarity, it’s worth understanding the data structure that makes it fast. A naive nearest-neighbour search compares a user’s vector against every item vector — an O(n) scan that is far too slow across billions of items. Production systems instead use approximate structures that trade a small amount of accuracy for enormous speed gains:

• HNSW (Hierarchical Navigable Small World graphs): Builds a multi-layer graph where each layer is a progressively sparser “skip list” over the vector space. Search starts at the sparse top layer and descends, following greedy nearest-neighbour hops, landing in the right neighbourhood in roughly logarithmic time instead of linear time.
• IVF (Inverted File Index) with Product Quantisation: Clusters the vector space into buckets (via k-means or similar), and at query time only searches within the nearest few buckets rather than the whole space. Product quantisation additionally compresses vectors so that millions of them fit comfortably in memory.
• Locality-Sensitive Hashing (LSH): Uses hash functions specifically designed so that similar vectors are more likely to collide into the same bucket, turning similarity search into a hash-table lookup followed by a small local comparison.

All three sacrifice a small amount of recall (they may occasionally miss the true nearest neighbour) in exchange for search times that are orders of magnitude faster — a trade every large-scale feed system happily makes, because “the 3rd-best match found in 2ms” beats “the perfect match found in 2 seconds” when a request has a 150ms total budget.

3.7 CAP Theorem in the Context of a Feed

The CAP theorem states a distributed data store can only guarantee two of Consistency, Availability, and Partition tolerance at once. Feed systems make a very deliberate choice here: they favour availability and partition tolerance over strict consistency. It is completely acceptable — even expected — for a user’s feed to reflect engagement data that is a few seconds or minutes stale, because a slightly stale but available feed is a far better user experience than a perfectly consistent but occasionally unavailable one. This is why the feature store, embedding store, and event pipelines are all built on eventually-consistent, highly-available data stores rather than strongly-consistent transactional databases.

A single high-level picture of the request path, the async learning loop, and the shared stores that connect them.

Below is the high-level architecture of a production “For You” feed system, structured around the funnel described in Section 3.

4.1 Component Responsibilities

Zooming into the three funnel stages one level deeper — how retrieval blends multiple strategies, how the ranking model actually scores, and how re-ranking greedily builds the final slate.

5.1 Candidate Generation in Detail

Candidate generation trades accuracy for speed. It typically blends several independent retrieval strategies running in parallel, then merges (and deduplicates) their outputs:

• Embedding-based retrieval (Approximate Nearest Neighbour): Both users and items are represented as dense vectors (embeddings) in the same vector space, learned so that “similar taste” users and “relevant” items end up close together. At request time, the system does an ANN lookup (using algorithms like HNSW or product quantisation) to find the top-K items nearest to the user’s embedding, in milliseconds, out of billions.
• Graph-based retrieval: For platforms with a social graph, pull recent content from followed accounts or “friends of friends.”
• Trending/popularity retrieval: A pool of currently high-velocity content (rapid recent engagement growth), refreshed continuously — this is a major channel for freshness.
• Cold-start/exploration retrieval: A reserved pool of very recent items with little to no engagement history, sampled using content-based similarity rather than collaborative signals.

5.2 Ranking in Detail

The ranking model is almost always a multi-task deep neural network that predicts several probabilities simultaneously for each (user, candidate) pair — for example: P(click), P(watch to completion), P(like), P(share), P(hide/“not interested”), P(report). These are combined into a single utility score via a weighted formula tuned by the product team, e.g.:

utility = w1·P(watch_completion) + w2·P(like) + w3·P(share)
        − w4·P(hide) − w5·P(report)

This multi-task setup exists because optimising for a single signal like clicks alone famously produces clickbait — the model learns to maximise the metric you gave it, so you must give it a metric that reflects genuine long-term satisfaction, not just an instant reaction.

Java: Simplified Utility Scoring Service

public class RankingUtilityScorer {

    // Product-owned weights: pushed via config, not code deploys
    private static final double W_WATCH  =  1.6;
    private static final double W_LIKE   =  1.2;
    private static final double W_SHARE  =  2.0;
    private static final double W_HIDE   = -3.0;
    private static final double W_REPORT = -5.0;

    /**
     * Combines multiple predicted probabilities from the multi-task model
     * into a single utility score used for ranking.
     */
    public double computeUtility(TaskPredictions predictions) {
        double utility =
              W_WATCH  * predictions.getWatchCompletionProb()
            + W_LIKE   * predictions.getLikeProb()
            + W_SHARE  * predictions.getShareProb()
            + W_HIDE   * predictions.getHideProb()
            + W_REPORT * predictions.getReportProb();

        // Clamp to avoid runaway scores destabilising downstream re-ranking
        return Math.max(0.0, Math.min(utility, 10.0));
    }
}

class TaskPredictions {
    private final double watchCompletionProb;
    private final double likeProb;
    private final double shareProb;
    private final double hideProb;
    private final double reportProb;

    public TaskPredictions(double watchCompletionProb, double likeProb,
                           double shareProb, double hideProb, double reportProb) {
        this.watchCompletionProb = watchCompletionProb;
        this.likeProb            = likeProb;
        this.shareProb           = shareProb;
        this.hideProb            = hideProb;
        this.reportProb          = reportProb;
    }
    public double getWatchCompletionProb() { return watchCompletionProb; }
    public double getLikeProb()            { return likeProb; }
    public double getShareProb()           { return shareProb; }
    public double getHideProb()            { return hideProb; }
    public double getReportProb()          { return reportProb; }
}

5.3 Re-ranking: Freshness Decay + Diversity in Practice

The re-ranking stage takes the top-N scored candidates and greedily builds the final slate, applying a diversity-aware selection algorithm (a simplified Maximal Marginal Relevance approach) plus a time-decay adjustment.

import java.util.*;
import java.util.stream.Collectors;

public class FeedReRanker {

    private static final double DECAY_LAMBDA           = 0.02; // tuned per content type
    private static final double DIVERSITY_PENALTY      = 0.35;
    private static final int    MAX_PER_CATEGORY_IN_WINDOW = 2;
    private static final int    WINDOW_SIZE            = 10;

    /** Applies exponential freshness decay to the raw ranking score. */
    private double applyFreshnessDecay(ScoredItem item) {
        double ageHours    = item.getAgeInHours();
        double decayFactor = Math.exp(-DECAY_LAMBDA * ageHours);
        return item.getRawScore() * decayFactor;
    }

    /**
     * Greedy diversity-aware selection (Maximal-Marginal-Relevance style):
     * pick the highest-scoring item, then penalise subsequent items that are
     * too similar (same category/creator) to what's already been selected
     * within a sliding window.
     */
    public List<ScoredItem> reRank(List<ScoredItem> candidates, int slateSize) {
        List<ScoredItem> selected = new ArrayList<>();
        List<ScoredItem> pool     = new ArrayList<>(candidates);

        // Pre-apply freshness decay to all candidates
        for (ScoredItem item : pool) {
            item.setAdjustedScore(applyFreshnessDecay(item));
        }

        while (selected.size() < slateSize && !pool.isEmpty()) {
            pool.sort((a, b) -> Double.compare(b.getAdjustedScore(), a.getAdjustedScore()));
            ScoredItem best = pool.get(0);

            // Diversity penalty based on recent window composition
            List<ScoredItem> window = selected.stream()
                .skip(Math.max(0, selected.size() - WINDOW_SIZE))
                .collect(Collectors.toList());

            long sameCategoryCount = window.stream()
                .filter(s -> s.getCategory().equals(best.getCategory()))
                .count();

            if (sameCategoryCount >= MAX_PER_CATEGORY_IN_WINDOW) {
                // Penalise this item's score and re-evaluate rather than
                // outright dropping it -- it may still win if scores are close.
                best.setAdjustedScore(best.getAdjustedScore() * (1 - DIVERSITY_PENALTY));
                pool.sort((a, b) -> Double.compare(b.getAdjustedScore(), a.getAdjustedScore()));
                best = pool.get(0);
            }

            selected.add(best);
            pool.remove(best);
        }
        return selected;
    }
}

class ScoredItem {
    private final String itemId;
    private final String category;
    private final double rawScore;
    private final double ageInHours;
    private       double adjustedScore;

    public ScoredItem(String itemId, String category, double rawScore, double ageInHours) {
        this.itemId        = itemId;
        this.category      = category;
        this.rawScore      = rawScore;
        this.ageInHours    = ageInHours;
        this.adjustedScore = rawScore;
    }
    public String getItemId()       { return itemId; }
    public String getCategory()     { return category; }
    public double getRawScore()     { return rawScore; }
    public double getAgeInHours()   { return ageInHours; }
    public double getAdjustedScore(){ return adjustedScore; }
    public void   setAdjustedScore(double s) { this.adjustedScore = s; }
}

Two loops run continuously side-by-side — a fast online serving loop and a slow offline learning loop — and understanding how they connect is essential.

There are two loops running continuously: the online serving loop (fast, request-driven) and the offline learning loop (slower, batch or streaming-driven). Understanding both — and how they connect — is essential.

6.1 Item Lifecycle

Every design choice above trades one desirable property against another — making these explicit is the difference between an architecture and a wish-list.

7.1 Core Trade-off Matrix

At billion-user scale, the naive approach is off by many orders of magnitude — every component in the architecture exists to make an intractable problem tractable inside a strict latency budget.

At billion-user scale, the naive approach — score every item for every user — is off the table by many orders of magnitude. The entire architecture exists to make an intractable problem tractable within a strict latency budget.

8.1 Key Scaling Techniques

• Approximate Nearest Neighbour (ANN) search instead of exact search — trades a small amount of recall for orders-of-magnitude speedup, essential for embedding-based retrieval over billions of items.
• Model distillation / two-tower architectures for candidate generation — a lightweight model that can score millions of items per second, reserving the expensive deep model for the much smaller ranking stage.
• Feature precomputation — most user and item features are computed offline/streaming and cached, so the online path mostly does lookups, not heavy computation.
• Horizontal sharding of the vector index and feature store by user/item ID hash, so no single node holds the entire catalogue.
• Batching inference requests to the ranking model to maximise GPU/accelerator throughput.
• Feed caching — pre-computing and caching a short-lived feed for users, refreshed on interaction or after a TTL, reduces redundant computation for rapid repeat requests (e.g., pull-to-refresh).
• Little’s Law applied to capacity planning: L = λ × W — the number of in-flight ranking requests equals arrival rate times average service time, directly informing how many ranking service replicas are needed to hold latency steady under load.

8.2 Capacity Planning Example

Suppose the platform serves 5 million feed requests per second at peak, and each request takes an average of 40ms end-to-end in the ranking service. By Little’s Law, the number of concurrent in-flight requests is:

L = λ × W
L = 5,000,000 req/s × 0.04 s
L = 200,000 concurrent in-flight requests

If a single ranking service instance can safely hold 500 concurrent requests before queueing degrades latency, you need at least 200,000 / 500 = 400 instances, plus headroom (commonly 30–50%) for traffic spikes and failover — informing both the fleet size and the autoscaling policy.

8.3 Hardware and Serving Efficiency

At this scale, the choice of hardware for model inference is itself a major system-design decision, not an implementation detail to defer. Deep ranking models with millions of parameters run meaningfully faster on GPU or specialised accelerator hardware than on general-purpose CPUs, but accelerators are expensive and must be shared efficiently across the whole platform.

• Dynamic batching: Instead of running inference one request at a time, the serving layer accumulates requests arriving within a very short window (a few milliseconds) and runs them through the model together as a batch, dramatically improving accelerator utilisation without noticeably increasing per-request latency.
• Quantisation: Converting model weights from 32-bit floating point to lower-precision formats (like 16-bit or 8-bit integers) shrinks memory footprint and speeds up computation, usually with a negligible, carefully-measured accuracy cost.
• Model distillation: Training a smaller “student” model to mimic the outputs of a larger, more accurate “teacher” model, so the fast candidate-generation stage benefits from the teacher’s learned patterns without paying the teacher’s full inference cost.
• Right-sizing per stage: Candidate generation typically runs on CPU-optimised fleets since its models are intentionally lightweight; ranking typically runs on GPU/accelerator fleets since accuracy there directly drives the product’s core quality.

8.4 Sharding Strategy

No single machine can hold a billion users’ features or a multi-billion-item vector index, so both are sharded (partitioned) across many machines. A common approach hashes the user ID or item ID to determine which shard owns that record, using consistent hashing so that adding or removing shards only requires moving a small fraction of the data rather than a full reshuffle. Read traffic for a given user’s features is then routed to exactly the shard that owns that user, keeping lookups fast and predictable even as the fleet grows.

A blank feed is one of the most visible failures a consumer app can produce — every stage of the funnel needs a fallback path baked in from day one.

A feed system must degrade gracefully — a broken feed is one of the most visible possible failures for a consumer app, so every stage needs a fallback.

9.1 Redundancy and Replication

• Vector indexes and feature stores are replicated across availability zones; reads are served from local replicas to minimise latency.
• Ranking model servers run as stateless, horizontally-scaled replicas behind a load balancer — any instance can serve any request.
• Event ingestion (Kafka/Kinesis) uses partition replication so a broker failure doesn’t lose engagement data needed for retraining.

9.2 Disaster Recovery and Backup

Beyond day-to-day redundancy, the system needs a plan for larger-scale failure scenarios: an entire cloud region becoming unreachable, a corrupted feature-store deployment, or a bad model rollout that isn’t caught by canary checks quickly enough. Key practices include:

• Regular index and feature-store snapshots: Periodic backups of the vector index and feature store allow rebuilding a region’s serving stack from a known-good state rather than depending entirely on live replication.
• Model registry with version pinning: Every deployed model version is retained and instantly re-deployable, so a bad rollout can be rolled back to the last known-good version within minutes rather than requiring retraining.
• Recovery time and recovery point objectives (RTO/RPO): The team defines concrete targets — for example, an RTO of a few minutes for full regional failover, and an RPO of a few seconds for engagement-event data loss tolerance — and architecture decisions (replication factor, snapshot frequency) are chosen to meet them.
• Game days / chaos engineering: Deliberately injecting failures (killing ranking service instances, simulating a region outage) in a controlled way to verify that fallback paths and alerting actually work, rather than discovering gaps during a real incident.

A feed system holds some of the most sensitive behavioural data on the platform — and is a large, tempting adversarial surface for anyone wanting to game the ranking.

• Authentication & authorisation: Every feed request is tied to an authenticated session; content visibility rules (blocked users, private accounts, age-restricted content) must be enforced before an item ever enters the candidate pool, not as an afterthought.
• Adversarial engagement / manipulation: Bot farms and coordinated inauthentic behaviour try to game engagement signals to boost content artificially. Systems need anomaly detection on engagement velocity and graph structure to down-weight or discard suspicious signals before they influence ranking or training data.
• Content safety filters: A dedicated trust & safety scoring pass (often a separate model) must run before or alongside ranking to exclude policy-violating content, independent of how “relevant” it scores.
• Data privacy: User behavioural data used for personalisation is highly sensitive; access to raw event logs and embeddings should follow least-privilege principles, and personalisation data should respect regulatory constraints (e.g., GDPR-style consent and deletion rights) on a per-user basis.
• Model security: Ranking/retrieval models can be targeted by adversarial inputs designed to game the algorithm (e.g., content engineered to maximise predicted watch-time without genuine value) — ongoing red-teaming and anomaly monitoring on content performance distributions helps catch this.

10.1 Threat Modelling for a Feed System

A useful exercise is walking through the request path and asking, at each hop, “what’s the worst thing a malicious actor could do here, and what stops them?” This surfaces several categories of concern beyond the ones already covered:

Encryption in transit (TLS between all internal services, not just the public-facing API) and encryption at rest for the feature store and event logs are baseline expectations, along with strict least-privilege IAM roles so that, for example, the ranking service can read feature data but has no ability to write to the user metadata database.

System-level, product-level, and per-request observability — because “is my feed good?” is a very different question from “is my server up?”

11.1 System-Level Metrics

11.2 Product / ML-Level Metrics

11.3 Logging and Tracing

Beyond aggregate metrics, individual request-level observability matters for debugging quality issues that don’t show up as a clean metric regression. Distributed tracing (propagating a single trace ID across the gateway, candidate generation, ranking, and re-ranking hops) lets an engineer reconstruct exactly which candidates were retrieved, how each was scored, and why the final slate looks the way it does for a specific problematic user session — essential when investigating a complaint like “my feed suddenly looks completely wrong.” Structured logs at each stage (candidate counts returned per source, top-line ranking scores, diversity constraints triggered) should be sampled and retained long enough to support this kind of forensic debugging, while respecting the same data-privacy constraints that apply to the underlying behavioural data itself.

A ranking model is code, and code that ships to a billion users deserves the same rollout rigour as any core production service — canary, shadow traffic, automated rollback, and cost discipline.

12.1 Model Deployment Strategy

Ranking and retrieval models are deployed through a canary process, never a big-bang rollout:

1. Offline evaluation: New model candidate is validated against held-out historical data (offline metrics like AUC, NDCG).
2. Shadow traffic: New model scores live requests in parallel with the production model, but its scores aren’t shown to users — used to validate latency and score distribution sanity.
3. Canary rollout: New model serves a small percentage (e.g., 1–5%) of real traffic; online metrics (Section 11) are compared against the control group.
4. Progressive ramp-up: If metrics hold, traffic gradually increases (5% → 25% → 50% → 100%) with automated rollback triggers if any guardrail metric regresses.

12.2 Infrastructure Choices

• Model serving: Kubernetes-orchestrated fleets running inference servers (e.g., Triton, TensorFlow Serving), with GPU node pools for heavier ranking models and CPU pools for lighter candidate-generation models.
• Streaming infrastructure: Managed Kafka/Kinesis clusters for event ingestion; Flink/Spark Streaming jobs for real-time feature aggregation, deployed with checkpointing for exactly-once-ish processing guarantees.
• Feature store: A combination of an offline store (batch-computed features, e.g., in a data warehouse) and an online store (low-latency KV store) kept in sync, so training and serving see consistent features (avoiding training/serving skew).
• Multi-region deployment: Feed gateways and serving fleets deployed per region close to users, with feature stores/indexes regionally replicated to minimise cross-region latency.
• Infrastructure as Code: Terraform/Kubernetes manifests define serving fleets, autoscaling policies, and canary rollout pipelines, version-controlled and reviewed like any other code change.

12.3 Cost Optimisation

GPU/accelerator fleets for ranking inference and the compute needed for continuous retraining are among the largest line items in this system’s infrastructure budget, so cost discipline matters as much as raw scalability. Common levers include right-sizing candidate pool sizes (a smaller candidate set means less ranking compute per request, at some recall cost that must be measured against quality metrics), scheduling non-latency-sensitive batch training jobs on cheaper spot/preemptible compute, tiering storage so that older, rarely-accessed embeddings and features move to cheaper cold storage automatically, and continuously monitoring cost-per-request as a first-class operational metric alongside latency and quality, so that efficiency regressions are caught with the same rigour as latency regressions.

Different data has different physics — and one datastore rarely satisfies all of them at this scale.

13.1 Storage Systems Used

13.2 Caching Strategy

• Feed-level cache: A recently computed feed slate is cached per user for a short TTL (seconds to low minutes) to absorb rapid repeat requests (e.g., pull-to-refresh, app backgrounding/foregrounding).
• Feature cache: Hot user/item features cached in-memory (Redis/Memcached) to avoid repeated feature-store round-trips within a request.
• Embedding cache: Frequently accessed item embeddings cached close to the ranking service to reduce vector-store lookup latency.
• Cache invalidation: Event-driven invalidation on strong signals (e.g., user explicitly hides a category) combined with short TTLs for softer signals, balancing freshness of personalisation against cache hit rate.

13.3 Load Balancing

13.4 Replication and Consistency Choices

Different stores in this system make deliberately different consistency trade-offs based on what they hold:

• Vector index / embedding store: Read-heavy, tolerant of a few minutes of staleness when new embeddings are computed; typically replicated asynchronously across zones for low-latency local reads.
• Online feature store: Optimised for extremely low read latency with eventual consistency between the streaming write path and read replicas; a few seconds of staleness on most features is an acceptable trade for speed.
• Metadata database (creator info, policy flags): Usually backed by a more traditional relational or document store with stronger consistency guarantees, since incorrect policy-flag reads (e.g., serving content that should have been taken down) carry real risk.
• Event log: Append-only and partitioned for high write throughput, replicated synchronously within a cluster to avoid losing engagement data that both retraining and business analytics depend on.

This mix illustrates a broader principle: a large system rarely makes one global consistency decision. Instead, each data store’s consistency model is chosen deliberately based on the cost of being wrong versus the cost of being slow for that specific type of data.

The contract each service exposes — and the reason splitting the funnel into services beats a single monolith at this scale.

14.1 Core Service Boundaries

The system is decomposed into independently scalable microservices, each owned by a focused team:

• Feed Gateway API — the only service the client talks to; orchestrates calls to downstream services and assembles the final response.
• Candidate Generation Service — exposes an internal API like getCandidates(userId, context) -> List<ItemId>.
• Ranking Service — exposes scoreItems(userId, candidateIds, context) -> List<ScoredItem>, typically over gRPC for low-latency internal calls.
• Feature Store Service — exposes feature lookups, abstracting away the underlying storage systems from consumers.
• Event Ingestion API — a write-optimised endpoint (or SDK) clients use to report impressions/interactions.

Example: Feed Gateway REST API Contract

GET /v1/feed?cursor={cursor}&limit=20
Authorization: Bearer {token}

Response 200:
{
  "items": [
    {
      "itemId":    "vid_9F3xk2",
      "creatorId": "user_88213",
      "category":  "cooking",
      "score":     0.842,
      "reasonTag": "based_on_recent_activity"
    }
  ],
  "nextCursor":  "eyJvZmZzZXQiOjIwfQ==",
  "generatedAt": "2026-07-28T10:15:32Z"
}

14.2 Why Microservices (and Where It Hurts)

The reusable ideas this architecture leans on, and the tempting shortcuts that quietly wreck it.

15.1 Patterns Worth Knowing

15.2 Anti-patterns to Avoid

The habits that mature feed teams share — and the recurring failures that catch newer ones.

16.1 Best Practices

• Always pair a relevance-maximising objective with explicit freshness and diversity mechanisms — never assume relevance alone will “naturally” produce a healthy feed.
• Treat every ranking/config/weight change as a shippable experiment with pre-registered guardrail metrics, including long-term retention proxies, not just short-term engagement.
• Build cold-start handling (content-based embeddings + bounded exploration) into the core architecture from day one — retrofitting it later is painful.
• Instrument diversity and freshness as first-class metrics on every dashboard, not just engagement metrics.
• Design every hop for graceful degradation — timeouts and fallbacks are not optional extras.
• Keep offline and online feature computation logically unified (e.g., shared feature-transformation code) to minimise training/serving skew.

16.2 Common Mistakes

• Optimising purely for engagement metrics that are easy to measure short-term, at the expense of harder-to-measure long-term satisfaction.
• Under-investing in the candidate generation stage — a ranking model can only rank what candidate generation retrieves; poor recall here caps the whole system’s quality regardless of ranking sophistication.
• Rolling out global model changes without canarying, especially config-only changes (weight tweaks) that “feel” lower risk than code changes but aren’t.
• Treating diversity as a nice-to-have bolted on late rather than a core re-ranking objective measured continuously.
• Forgetting that explicit negative feedback (hide, report, unfollow) needs to propagate near-instantly, unlike most other features which can tolerate streaming-pipeline latency.

Every major platform independently converged on the same core shape — strong evidence the pattern reflects the problem, not an implementation quirk.

17.1 Side-by-Side Comparison

A rapid-fire tour of the questions that come up most often when engineers first meet this architecture.

Glossary of Key Terms

Designing a “For You” feed is fundamentally an exercise in balancing three genuinely opposed forces under a punishing latency and scale budget. The engineering patterns — funnels, embeddings, multi-task learning, bandits, canary deployments — are all in service of that one underlying tension. Master that tension conceptually, and the rest of the architecture follows logically from it.