Recommendation Engine

Personalized Video Recommendations

Design a recommendation system for a large video catalog: pick a few hundred candidates from millions with embeddings, rank them with a model, and serve a fresh, varied list in well under a second.

Overview

A recommendation engine chooses what each person sees on the home page: out of millions of videos, the few dozen they are most likely to enjoy right now. The signals are what people do: watches, how long they watch, likes, skips and searches.

Scoring every item for every request with a rich model is far too slow. So every large system is a funnel. Cheap methods narrow millions of items to about a thousand candidates; a bigger model ranks those; simple rules re-rank the top for variety and freshness. YouTube's 2016 paper describes exactly this two-stage split, candidate generation then ranking, and it is the shape interviewers expect.

This topic designs a generic video recommender. The numbers are interview assumptions. The TikTok problem covers a feed built mostly on recommendations, and the LinkedIn problem covers recommendations built on a social graph.

Questions to ask first

What is recommended, and where? — Videos, on the home page and as similar items on a video page
How many users and items? — 100 million daily users, 10 million items
What is success? — Time spent watching and returning, not just clicks
How fresh must results be? — Reflect what the user did minutes ago; new uploads appear within hours
What signals exist? — Watches with duration, clicks, likes, skips, searches; item metadata
Is there a latency budget? — About 100 ms for the whole recommendation call (a target we chose)

What you will be able to do

Explain the candidate generation, ranking and re-ranking funnel and budget its latency.
Describe a two-tower retrieval model and serve it with an approximate nearest neighbor index.
Choose training labels that match serving, and avoid leaking the future into training.
Keep features consistent between training and serving with point-in-time joins.
Handle cold start, diversity and exploration, and measure success with A/B tests.

Key concepts

Candidate generation
Two-tower model
Embeddings
Approximate nearest neighbors
Ranking model
Expected watch time
Feature store
Training-serving skew
Cold start
Exploration

Functional requirements

Return a ranked list of items for a user on the home page
Return items similar to a given item
Record events: impressions, clicks, watch time, likes, skips, not interested
Reflect a user's recent actions in their next request
Recommend new users and new items sensibly before they have history
Run A/B tests that compare models on live traffic

Non-functional requirements

p99 under 100 ms for a recommendation call (a target we chose)
Recent actions reflected within a few minutes; new items retrievable within hours
Serving degrades, never fails: fall back to popular items if a model or store is down
Train and serve from the same feature definitions
Event ingestion never blocks the app; events may arrive late or twice

Interview questions

Why split recommendation into candidate generation and ranking?
How does a two-tower model work, and why is it fast?
What should the ranking model predict?
How do you make a user's last few minutes count?
What is training-serving skew and how do you prevent it?
How do you handle cold start?
How do you avoid a filter bubble?
What happens when part of the system fails?