Design Recommendation Engine

Personalization rails for Netflix-scale catalogs

A recommendation engine decides, for a specific user at a specific moment, which handful of items out of a catalog of millions deserves the next slot on screen. At its core it is a ranking problem wrapped around a retrieval problem: you can never afford to score every item for every request, so the system first narrows millions of candidates down to a few hundred, then orders those few hundred with a heavier model.

The systems that made this pattern famous all share the same shape. Netflix ranks the rows on the home page; Amazon ranks "customers who bought this also bought"; Spotify ranks Discover Weekly. State the scale out loud before you draw a single box, because it constrains every later decision: roughly 250M monthly active users, on the order of 8 billion recommendation impressions per day, and a p95 latency budget near 80ms for the home feed — the request sits directly in the page-render path, so a slow ranker is a blank screen.

The funnel, not one big matrix multiply

The most important misconception to clear early is that a feed is one big model. It is not. It is a funnel, with compute cost rising and item volume falling at each stage:

1. Candidate generation (recall). Cut millions of items to a few thousand with cheap, approximate methods — embedding nearest-neighbor lookups, co-visitation, trending pools. Tuned so it does not miss good items.
2. Filtering. Drop the few thousand to a few hundred with hard business rules: already-seen, out-of-region, age-gated, out-of-stock.
3. Ranking (precision). Score the survivors with a learning-to-rank model that can now afford richer features, then apply diversity and exploration before returning the top-K.

Separating recall from precision is the load-bearing idea. Recall is judged by coverage and latency; ranking is judged by ordering quality. Collapse the two into one stage and you get either a system too slow to serve or a model too shallow to be accurate.

Where it breaks

The happy path is easy; the failure cases earn the credit. A cold-start user with fewer than five events has no meaningful embedding, so the funnel must fall back to popularity plus exploration instead of returning an empty feed. An index rebuild that lags the catalog serves stale embeddings and misses a breaking new release. Duplicate impressions across tabs quietly corrupt both the diversity SLO and the click-through metrics that train the next model. And in a multi-tenant catalog, any leakage across the candidate-pool boundary is a hard isolation failure, not a ranking bug.### How to open in the interview

Lead with the funnel out loud: events feed features, features feed a two-tower recall stage, recall feeds a re-ranker, and the re-ranker is constrained by diversity and business rules. Name the lineage briefly — Netflix's two-tower retrieval, Amazon's item-to-item collaborative filtering — so the interviewer hears that you are drawing on real systems rather than a generic microservice diagram. Then ask which surface (home feed, "more like this", search re-rank) and which objective (watch time, conversion, retention) they care about, because that choice changes the model, the features, and the latency budget you commit to next.