Paths Subjects Questions Quizzes Pricing Search

Case Study: Video Recommendation (YouTube / Netflix-style Homepage)

A complete model interview answer for designing a homepage video recommender, from objective to serving

Overview Read

Case Study: Video Recommendation (YouTube / Netflix-style Homepage)

"Design the homepage recommendations for a video platform" is the single most common ML system design prompt because it touches everything: a hard-to-define objective, billions of implicit labels, retrieval at web scale, multi-task ranking, bias, cold start, experimentation and a serving stack with a 200 ms budget. Interviewers use it to check that you can go from vague product goal to a concrete, defensible system, and that you know where the bodies are buried (position bias, feedback loops, offline–online metric gaps).

This subject is written as a model answer, organised by the 7-step framework taught in the ML System Design Framework subject: clarify → business to ML objective → data and labels → features → model → evaluation → serving and monitoring. The general theory of candidate generation, ranking architectures and learning-to-rank losses lives in the Ranking and Recommendation Systems subject; here we apply it and spend the words on the decisions and numbers an interviewer wants to hear. Read it as a script you would deliver in 40 minutes, with the numbers you would write on the whiteboard.

Numbers are stated as assumptions. Your job in an interview is to make them explicit, keep them consistent, and reason from them.


Step 1 — Clarify Requirements and Scale

State the questions you would ask, then the assumptions you proceed with.

Questions to ask

  • Surface: homepage feed only, or also "up next" / search? → Homepage feed.
  • Goal: engagement, satisfaction, retention, revenue? → Long-term satisfied engagement; ads exist but are out of scope.
  • Content: user-generated (millions of uploads/day, long-tail) or licensed catalogue (tens of thousands of titles)? → UGC-style: 100M+ videos, ~500k new per day.
  • Users: logged in with history, or many anonymous/new? → Mostly logged in; ~5% new/anonymous per day.
  • Latency and freshness: how fast must the homepage render; how quickly must a new upload be recommendable? → p99 200 ms for the recommendation call; new videos eligible within an hour.
  • Constraints: diversity, creator fairness, policy/safety filtering, regional catalogue rules? → Yes to all; a policy filter exists upstream.

Assumptions written on the board

Users (MAU)                 1B ; DAU ~ 400M
Homepage loads / day        ~ 4 per DAU   1.6B requests/day  ~18.5k QPS avg,
                            ~ 55k QPS peak (3× avg)
Videos in corpus            100M+ (only ~10M "active" candidates)
Impressions per homepage    ~ 30 slots (first screen ~ 6)
Latency budget              p99 200 ms end-to-end for recs (retrieval + ranking)
Freshness                   new video eligible  1 h; user history updates  minutes
Logging                     ~ 1.6B × 30 = 48B impressions/day  training data is not scarce

The scale numbers immediately dictate the architecture: you cannot score 10M videos per request in 200 ms, so you need a multi-stage funnel (retrieval → ranking → re-ranking), and you cannot fetch heavy user features per candidate, so features must be precomputed and cached.


Pro content

Sign up free, then start a 14-day Pro trial — no card needed.

We use cookies for product analytics to improve OmniAtlas. See our Privacy Policy.