# Recommendation systems > Recommendation systems select and order items a user is likely to find useful, such as videos or nearby profiles. In system design interviews, the challenge is connecting candidate retrieval, ranking, feedback collection, and reliable serving without scanning the entire catalog on every request. Source: https://sysround.com/concepts/recommendation-systems Updated: 2026-11-05 ## How recommendation systems works Start with the recommendation surface and objective. A short-video feed might optimize for satisfying viewing sessions, while profile discovery must respect location, preferences, and blocks. Define eligibility rules, latency targets, and acceptable feedback delay before choosing models. Collect impressions and outcomes through a durable event pipeline. Record what was actually displayed, its position, the model version, and subsequent actions such as skips or likes. Deduplicate retried events and account for late arrivals; otherwise, both training data and evaluation can be misleading. Build candidates cheaply before doing expensive ranking. Combine sources such as items liked by similar users, content with similar attributes, followed creators, and regional trends. Collaborative filtering learns from interaction patterns; content-based retrieval uses item attributes or embeddings. Vector search can retrieve a few hundred similar items without scoring the whole catalog. Rank the retrieved candidates using user, item, and request-context features. Offline jobs can train models and compute embeddings, while streaming jobs update recent interests and counters. Keep feature definitions and model versions compatible between training and serving so the model sees comparable inputs. Rerank for diversity, freshness, and repetition limits, then return a page with an opaque cursor. Apply eligibility filters before ranking where practical, and recheck mutable safety or privacy restrictions before returning results. A cached ranking must not authorize a blocked profile or deleted item. Close the loop with fresh feedback and controlled experiments. Update session features after a skip rather than retraining the entire model synchronously. Measure retrieval quality, end-to-end latency, feature freshness, and product outcomes; use eligible cached or popular items when retrieval or ranking misses its deadline. ## Worked example: A short-video feed with a bounded ranking path Assume a catalog of 10 million eligible videos, 5,000 feed requests per second, and a 150 ms server-side latency target. Retrieve 1,000 candidates across embedding similarity, followed creators, and regional trends. Filter and deduplicate them, rank 300, and return 20 after diversity and eligibility checks. At this rate, the ranker evaluates 1.5 million user-video pairs per second, which provides a concrete capacity-planning input. Stream skips and completed views into session features with a target delay below five seconds; refresh item embeddings in background jobs. If ranking times out, use a cached candidate list but recheck current eligibility. Preserve a recommendation-session cursor and served-item history to avoid repeats across pages. ## Trade-offs - **Recommendation quality versus serving cost.** Larger candidate pools and more expensive rankers may improve relevance, but increase compute cost and tail latency. - **Precomputation versus freshness.** Precomputed candidates make reads cheap, while request-time retrieval and streaming features respond faster to changing interests. - **Exploration versus immediate relevance.** Showing some unfamiliar items helps discover interests and surface new content, but can reduce short-term engagement. - **Personalization versus cold-start coverage.** Interaction-based recommendations need history, so new users and items require content-based, contextual, or popularity-based alternatives. - **Availability versus degraded quality.** Fallback recommendations preserve service during model or feature-store failures, but must still satisfy eligibility and privacy rules. - **Engagement versus user value.** Optimizing only clicks or watch time can reinforce narrow feedback loops, so evaluate satisfaction, diversity, and negative feedback too. ## When to use it in a system design interview - The product needs a personalized discovery feed rather than a chronological list or an explicit keyword search. - The catalog is too large to score every eligible item for each request. - Recent behavior, such as skips or likes, should affect the next page within a defined freshness target. - New users and new items must receive useful recommendations despite having little interaction history. - The interview asks how to balance relevance, diversity, eligibility, and predictable serving latency. ## How to bring it up in the interview - Separate candidate retrieval, ranking, and reranking on the diagram; explain why expensive scoring runs only on a bounded subset. - Describe the online request path separately from event ingestion and training, including which features are precomputed and which update during a session. - State illustrative catalog size, request rate, candidate count, and latency budgets, then explain how those assumptions drive caching and compute needs. - Explain failure behavior explicitly: feature timeouts, stale embeddings, empty candidate pools, and cached results containing newly ineligible items are common follow-up probes. - Distinguish offline model evaluation from online product impact; interviewers may probe exposure logging, experiment assignment, feedback bias, and whether training used information unavailable at prediction time. ## Common mistakes - Naming a machine-learning algorithm without designing retrieval, feature access, feedback ingestion, and the serving path. - Scoring the entire catalog per request or making recommendation requests wait for model retraining. - Logging only clicks or likes, without impressions and positions needed to interpret what users actually saw. - Treating all staleness alike: an old interest score may be acceptable, but a stale block or deletion check may expose forbidden content. - Regenerating rankings for every page without a cursor or served-item history, causing duplicates and unstable pagination. ## Interview questions where it comes up - [Design TikTok](https://sysround.com/questions/design-tiktok): Personalized candidate retrieval, fresh viewing feedback, ranking latency, and stable page delivery are central to the swipe feed. - [Design a dating app like Tinder](https://sysround.com/questions/design-tinder): Profile discovery requires bounded candidate retrieval and ranking while enforcing location preferences, exclusion histories, and current privacy rules. ## FAQ ### How do you design a recommendation system for a system design interview? Define the recommendation surface, objective, eligibility rules, scale, and latency target first. Then design candidate retrieval, feature access, ranking, reranking, and feedback ingestion as separate stages. Cover cold starts, failures, freshness, and evaluation rather than spending the whole interview on model choice. ### What is the difference between candidate generation and ranking? Candidate generation cheaply reduces a large catalog to a manageable subset using similarity, interaction patterns, or simpler retrieval rules. Ranking applies more expensive user-item scoring to that subset. A strong ranker cannot recover a relevant item that candidate generation never retrieved. ### How do recommendation systems handle new users and new items? For new users, use onboarding preferences, request context, and broadly useful eligible items while collecting feedback. For new items, use metadata or content embeddings and reserve some exposure for exploration. Avoid requiring interaction history as the only route into the candidate pool. ## Related concepts - [Feature stores](https://sysround.com/concepts/feature-store) - [Vector databases and ANN search](https://sysround.com/concepts/vector-search) - [Stream processing](https://sysround.com/concepts/stream-processing) - [Caching strategies](https://sysround.com/concepts/caching-strategies) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.