Design Netflix's Recommendation Pipeline

Open Netflix and the whole screen is a recommendation: which rows, which titles, which artwork, in which order. Behind that screen is not one clever model but a data pipeline that turns hundreds of billions of tiny interactions a day, plays, pauses, scrolls, and the rows you ignored, into a ranked list waiting in a fast store before you even log in. The modeling gets the headlines. The pipeline is the system design problem.

Netflix serves this to roughly 250 million subscribers against a catalog of tens of thousands of titles, and it cannot compute a fresh ranking for every user on the request path. Aria, a data engineer on the personalization team, gets the prompt: "design the data pipeline behind recommendations." How events are collected, how they become a labeled training set, and how recommendations get precomputed and served fast enough that the home screen feels instant.

The subtle, defining difficulty is the labels. When you watch a title, that is a clear positive signal. But the thousands of titles you didn't watch are a riddle: did you dislike them, or did you simply never see them? Getting that wrong poisons every model downstream. This chapter is about the pipeline, and that riddle sits at its heart.

Step 1 - Understand the Problem and Establish Design Scope

"Build recommendations" spans modeling, ranking, serving, and data. The clarifying questions carve out the data pipeline and surface the label problem early.

Candidate: Are we designing the model, or the data pipeline around it?

Interviewer: The pipeline. Assume a model exists that, given features and training data, produces rankings. Your job is the data: collect the signals, build training data, and serve recommendations. The model is a black box you feed and deploy.

Candidate: What signals do we collect, and at what scale?

Interviewer: Every interaction. Plays, how long someone watched, pauses, ratings, adds to My List, searches. And crucially, impressions: every title we showed a user, in what row and position, whether or not they clicked. Impressions vastly outnumber plays.

Candidate: How do we know if a recommendation was good? What is the label?

Interviewer: That is the interesting part. A play is a positive. But a title a user didn't play is ambiguous: they might dislike it, or they might never have scrolled to it. We only have clear positives; negatives have to be inferred.

Candidate: How fresh do recommendations need to be?

Interviewer: Mixed. The core ranking can be recomputed on a batch cadence, hours old is fine. But if you just finished a show, the home screen should reflect that within seconds, not wait for the next batch.

Candidate: Can we compute recommendations at request time?

Interviewer: No. Ranking tens of thousands of titles for 250 million users on the request path is not feasible in the latency budget. Recommendations are precomputed; serving is a lookup.

Candidate: Two things I want to confirm are in scope: turning ambiguous non-plays into training data, and the fact that our own recommendations influence what users click.

Interviewer: Both in scope. The second one is a trap a lot of people miss.

With that, the requirements are clear.

Functional requirements

• Collect interaction events (plays, watch duration, ratings, list adds) and impression events (what was shown, where) at full scale.
• Build a labeled training set from implicit feedback: clear positives from plays, inferred negatives from non-plays.
• Precompute ranked recommendations per user and serve them with a fast lookup.
• Keep recommendations reasonably fresh, with a faster path for very recent activity.
• Feed interaction outcomes back into the next training cycle.