Scoping the Product, and Its Stakeholders
In one line: "recommendation system" is not a specification, and the four questions that turn it into one also decide most of the architecture.
Which surface
A homepage feed, a related-items rail, a notification, an email digest and an autoplay queue are all recommenders and almost nothing about them is shared.
| Surface | Intent | Slate | Latency | Failure |
|---|---|---|---|---|
| Homepage feed | None — the user arrived with nothing in mind | Large, scrollable | Tens of ms | Nothing worth stopping for |
| Related items | Strong, anchored to the current item | Small | Tens of ms | Irrelevant to the anchor |
| Notification | None, and you interrupted them | One | Minutes to hours | Annoyance, then uninstall |
| Email digest | None, hours later | ~5 | Hours | Unsubscribe |
| Autoplay | Continuation | One | Must be ready before the current item ends | The chain breaks |
The notification row is the one worth dwelling on. It is the only surface where a mediocre recommendation is worse than none, because the cost of interrupting is paid whether or not the content lands. That single property changes the design: you need a confidence threshold and a send-nothing option, which no other surface requires.
At what scale
Three numbers, and they choose the architecture between them.
Catalogue size. A few thousand items and you can score everything for every user — no candidate generation, no ANN index, no funnel. Millions of items and the funnel is forced. Say this out loud, because proposing a two-stage cascade for a catalogue of eight hundred items is over-engineering that an interviewer will notice.
Request rate. Peak requests per second sets the serving budget and decides whether ranking can be online at all.
Interaction density. Interactions divided by users times items. Collaborative filtering needs a signal, and below roughly a few interactions per user it has nothing to work with — which pushes you toward content features whether you like it or not.
With what freshness
Two different freshness questions, and candidates routinely merge them.
Item freshness — how quickly must a new item become recommendable? A news feed measures this in minutes; a film catalogue in days. This decides whether the item tower can run in nightly batch.
Signal freshness — how quickly must the user's last action change what they see? "I just watched this, stop showing it to me" is a seconds-level requirement, and it is usually handled outside the model in the policy layer rather than by retraining anything.
Conflating them produces a design that retrains hourly to achieve something a dedup rule does instantly.
For whom — the part that makes this hard
A search engine has one stakeholder: the searcher. A recommender usually has at least three, and their interests genuinely conflict.
Users want relevance now and value over time, which are not the same thing.
Suppliers — creators, sellers, publishers, artists — need distribution to keep supplying. A system that concentrates all traffic on established winners maximises short-term engagement and starves the supply that feeds it next year.
The platform wants retention, revenue and defensible position, on a longer horizon than either.
This is the multi-stakeholder framing, and published work on popularity bias treats it as the core issue rather than a side effect. A purely engagement-optimal ranking concentrates exposure on already-popular items, which is individually reasonable for each impression and collectively a supply problem.
The design consequence is concrete: some constraints cannot be expressed as a better loss function, because they are about the distribution of exposure across items rather than the quality of any one slate. Those live in the policy layer.
What to commit to
Having asked, commit out loud. Something like:
A homepage feed for a video platform. Roughly ten million items, a hundred million monthly users, a few hundred thousand requests per second at peak. New items must be recommendable within about an hour, and the user's last action must affect the next request. Optimising for long-term satisfaction, proxied by a combination of watch time and predicted survey score, with retention and creator diversity as guardrails.
Every number there is a design constraint you will use later. The catalogue size forces the funnel. The request rate sets the budget. The one-hour item freshness rules out nightly-only item embeddings. The objective decides what the ranker predicts. And the creator guardrail is why there is a policy layer at all.
Key takeaway
Surface, scale, freshness and stakeholders. The surface decides whether a bad recommendation is ignored or costly, the catalogue size decides whether you need a funnel at all, and the two freshness questions have completely different answers. The multi-stakeholder framing is the one candidates skip: some constraints are about the distribution of exposure across items and cannot be expressed as a better loss.
Next: the funnel, sized for the product you just committed to.