Recommendation System

01What is the recommender optimizing — clicks, watch time, or something closer to long-term value?

The business goal is translated into an explicit ML objective before any architecture: a pure click model drowns the feed in clickbait, a watch-time model favors long sessions, and most platforms optimize a weighted blend approximating long-term satisfaction — the choice shapes labels, features, and every metric downstream. One platform then serves several surfaces — home feed, similar-items rails, video tab — with shared retrieval, feature, and experiment infrastructure and per-surface ranking policies.

02Where do candidates come from — a single model?

Candidates are merged from several sources: two-tower embedding retrieval, item-to-item similarity, trending, follow/graph edges, and business campaigns — no single source covers every user state.

03We have 100M items and 100 slots on screen. What happens in between?

A multi-stage funnel narrows the catalog: retrieval to a few thousand candidates, a light ranker to a few hundred, a heavy ranker over the survivors, then a blender applies diversity and business rules.

04Will the user see the same item again tomorrow?

Exposure is remembered: impressions are logged per user, and recently shown items are filtered or demoted at retrieval time so the feed does not repeat itself.

05What does a day-one user see — and when does a day-one item first appear?

Cold start works on both sides: new users get popularity priors shaped by onboarding interests; new items enter through content embeddings plus a reserved exploration slice of traffic.

06A new model wins offline. Do we just ship it?

Every ranking change ships through an experiment: offline metrics as the gate, then an A/B against guardrail metrics, with a long-term holdback group to catch slow damage.

01What is the latency budget, end to end?

p95 under roughly 200 ms for the whole recommendation call — this one number is what forces the funnel shape and the feature-store design.

02I hide an item. Does the very next request know?

Freshness is tiered, not uniform: the last few actions influence the very next request (seconds), counters lag minutes, long aggregates and embeddings lag hours to a day.

03Can training data quietly diverge from what serving saw?

Point-in-time correctness is a hard requirement: the model trains only on feature values as they existed at the moment of each impression — ideally the logged served values themselves.

04The heavy ranker is down. What does the user see?

The surface always renders: if ranking degrades, serve cached results, then a popularity fallback — a generic feed beats an empty one.

05A launch goes wrong. How fast can we know, and undo it?

Every response carries a trace (model version, experiment arm), guardrails are monitored per model, and rollback is a registry pointer swap, not a redeploy.