System Design/general/Improve YouTube Recommendation Algorithm

Improve YouTube Recommendation Algorithm

HARD45 minRecommendationMachine LearningYoutubeScalabilityUser ExperienceData PlatformML System Design

Design improvements to YouTube's recommendation system focusing on relevance, diversity, freshness, trust, and scalable ML infrastructure.

Design improvements to YouTube's recommendation system focusing on relevance, diversity, freshness, trust, and scalable ML infrastructure. Use this guide to structure the discussion, test the design under pressure, and practise explaining trade-offs clearly.

Problem and Scope

Design improvements to YouTube's recommendation algorithm. Focus on boosting relevance and engagement while reducing harmful or low-quality surfacing. Consider signals, model architecture, freshness, diversity, personalization, evaluation metrics, and how to serve recommendations at YouTube scale.

Start by confirming the core user journey, exclusions, success criteria, and the constraints that materially affect the architecture.

Requirements to Clarify

A strong answer should establish scope before choosing components.

Functional requirements:

  • Functional: produce ranked candidate videos tailored to a user context (homepage, up-next, search follow-up).
  • Non-functional: 100s ms end-to-end latency for front-end, high availability, per-region scaling.
  • Metrics: increase long-term user satisfaction, reduce clickbait and harmful content, maintain or improve watch time.
  • Constraints: user privacy, minimal degradation during rollout, limited compute cost growth.

Non-functional requirements:

  • Serve recommendations within the stated tail-latency budget at global request volume
  • Keep features and candidates fresh while providing highly available degraded recommendations
  • Balance satisfaction, safety, diversity, creator fairness, and engagement rather than optimizing a single proxy
  • Respect privacy and regional policy while limiting serving and training cost growth
  • Support reproducible experiments, model monitoring, canary rollout, and rapid rollback

Scale and Capacity

Use the workload to justify storage, partitioning, caching, and reliability decisions. Clarify or challenge these assumptions rather than treating them as unquestionable facts:

  • Users: ~2B+ monthly users globally.
  • Content: hundreds of millions of active videos, millions uploaded per day.
  • Requests: tens of millions of recommendation requests per second peak across endpoints.
  • Storage: petabytes for raw logs, model features and embeddings; exabytes over time for full ingestion.
  • Serving: need to serve ranked lists with sub-200ms p95 latency per request.

Architecture Discussion

Walk through the important read and write paths, identify ownership boundaries, and explain how the design behaves when dependencies fail. Cover these areas explicitly:

  • Product objective, long-term satisfaction metrics, and safety or quality guardrails
  • Candidate generation from subscriptions, similarity, trends, and exploration
  • Feature pipelines, online feature freshness, embeddings, and training data
  • Multi-stage ranking, calibration, diversity, and policy-aware reranking
  • Low-latency serving, caching, fallbacks, and global capacity
  • Cold start, feedback loops, bias, experimentation, monitoring, and rollback

Follow-up Questions

Expect the interviewer to test the consequences of your choices. Practise answering these questions with a concrete decision, its benefit, and its cost:

  • What does "improve" mean: higher watch time, user satisfaction, retention, or trust?
    • Focus: Assess the candidate's answer to "What does "improve" mean: higher watch time, user satisfaction, retention, or trust" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
  • Are we targeting all users globally or a subset (new users, logged-in users)?
    • Focus: Assess the candidate's answer to "Are we targeting all users globally or a subset (new users, logged-in users)" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
  • Are we allowed to change UI/UX or only backend ranking?
    • Focus: Assess the candidate's answer to "Are we allowed to change UI/UX or only backend ranking" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
  • Constraints: latency SLOs, compute budget, privacy/regulatory limits?
    • Focus: Assess the candidate's answer to "Constraints: latency SLOs, compute budget, privacy/regulatory limits" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
  • How to evaluate long-term satisfaction vs. immediate engagement? Describe experiments and instrumentation.
    • Focus: Assess the candidate's answer to "How to evaluate long-term satisfaction vs. immediate engagement? Describe experiments and instrumentation." for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
  • Discuss cold-start for new creators and new users.
    • Focus: Assess the candidate's answer to "Discuss cold-start for new creators and new users." for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
  • Propose approaches for cross-device personalization and privacy-preserving personalization (federated learning, differential privacy).
    • Focus: Assess the candidate's answer to "Propose approaches for cross-device personalization and privacy-preserving personalization (federated learning, differential privacy)." for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
  • How to handle multilingual and regional content fairness?
    • Focus: Assess the candidate's answer to "How to handle multilingual and regional content fairness" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.

Evaluation Rubric

MockMe evaluates the answer across the following dimensions. A complete answer should connect claims to requirements and explain consequential trade-offs.

  • Requirements and scope (15%): Clarifies and prioritizes the required behavior for Functional: produce ranked candidate videos tailored to a user context (homepage, up-next, search follow-up); Non-functional: 100s ms end-to-end latency for front-end, high availability, per-region scaling; Metrics: increase long-term user satisfaction, reduce clickbait and harmful content. Establishes the constraints that materially affect Improve YouTube Recommendation Algorithm, including Serve recommendations within the stated tail-latency budget at global request volume; Keep features and candidates fresh while providing highly available degraded recommendations. Strong evidence includes Separates the critical path from secondary features and resolves ambiguous requirements before choosing components.
  • Architecture and interfaces (20%): Presents coherent ownership boundaries and end-to-end flows covering Product objective, long-term satisfaction metrics, and safety or quality guardrails; Candidate generation from subscriptions, similarity, trends, and exploration; Feature pipelines, online feature freshness, embeddings, and training data; Multi-stage ranking, calibration, diversity, and. Strong evidence includes Defines interfaces and traces important success, retry, and failure paths across the proposed components.
  • Data and scaling (25%): Uses workload assumptions such as Users: ~2B+ monthly users globally; Content: hundreds of millions of active videos, millions uploaded per day to justify capacity and partitioning decisions. Explains the data, state, or model strategy for Feature pipelines, online feature freshness, embeddings, and training data; Multi-stage ranking, calibration, diversity, and policy-aware reranking. Strong evidence includes Quantifies a dominant workload, identifies the first bottleneck, and explains how the design evolves as that workload grows.
  • Reliability, correctness, and safety (20%): Explains concrete failure behavior, recovery, and operational safeguards for Cold start, feedback loops, bias, experimentation, monitoring, and rollback; Keep features and candidates fresh while providing highly available degraded recommendations; Respect privacy and regional policy while limiting serving and training cost growth. Strong evidence includes States the required correctness or consistency boundary and covers retries, partial failure, observability, and safe degradation.
  • Communication and trade-offs (20%): Drives a structured discussion and compares consequential alternatives for Multi-stage ranking, calibration, diversity, and policy-aware reranking; Low-latency serving, caching, fallbacks, and global capacity; Cold start, feedback loops, bias, experimentation, monitoring, and rollback. Strong evidence includes Makes assumptions explicit, answers the question asked, and explains both the benefit and cost of major decisions.

Ready to practice this question?

Run a mock system design interview with AI coaching and detailed feedback.