Scaling Matching and Recommendations
Recommendation systems drive engagement on platforms like YouTube, Netflix, and Tinder. At a high level, these systems operate in a funnel architecture: from millions of possible candidates down to a ranked list of a dozen items presented to the user.
The Two-Stage Funnel
- Candidate Generation (Retrieval): The goal is to quickly reduce the corpus from billions to hundreds. Speed is critical. This stage uses lightweight algorithms:
- Collaborative Filtering (Matrix Factorization)
- Two-Tower Deep Learning Models (User embeddings and Item embeddings)
- Approximate Nearest Neighbor (ANN) search using FAISS to find similar embeddings in vector databases.
- Ranking (Scoring): The goal is precision. The system takes the hundreds of candidates and scores them using a heavy, complex machine learning model (e.g., Deep Neural Networks, XGBoost). This model incorporates dense features (time of day, context, detailed user history) to predict the probability of engagement (click, watch, swipe right).
Geospatial Matching (The Tinder Model)
For apps like Tinder or Uber, recommendations are heavily constrained by geography. The candidate generation phase is primarily a geospatial query (using Geohash or S2) combined with filters (age, gender, vehicle type). Only users within the active Geohash cells are pulled into the ranking phase. Machine learning models then rank the nearby candidates based on predicted mutual interest. (Early Tinder used an Elo-style desirability score; Tinder said in 2019 that it no longer relies on Elo.)
Infrastructure
Candidate generation and ranking must use features available at serving time. Training on a future conversion, post-match outcome, or a feature computed after the recommendation creates leakage and an offline score that production cannot reproduce. Version model, embedding, feature schema, and ANN index together; during rollout, log which versions produced each result.
Failure and tradeoff: if the feature store is unavailable, choose a bounded fallback such as popular eligible items rather than silently treating missing features as zero. Fresh streaming features improve responsiveness but add ordering and training/serving-skew risk; slower batch features are easier to reproduce. Evaluate retrieval recall and ranking quality offline, then validate engagement, diversity, safety, and long-term feedback effects online. Reserve some exploration so the existing ranker does not permanently hide new items.
Worked example: a 150 ms budget
Corpus: 100 million items. Target: return 20 items in 150 ms at the 99th percentile.
- Candidate generation (about 20 ms): compute the user embedding from a two-tower model, run approximate nearest neighbour search (for example HNSW) for the top 500, plus 300 from "followed creators" and 200 from "trending in your region". HNSW indexes routinely reach about 95 percent recall at a few milliseconds per query.
- Filtering (about 5 ms): remove seen items (Bloom filter plus recent exact set), blocked creators and ineligible content: about 800 remain.
- Ranking (about 60 ms): a deep model scores 800 candidates in one batched call with hundreds of features each, predicting click, watch time and hide probability, combined into a single score.
- Re-ranking (about 5 ms): enforce diversity (at most 2 items per creator in the top 10), insert 1 to 2 exploration slots, return 20.
The remaining budget covers network hops and feature store reads. If the feature store times out, serve the cached popular-and-eligible list for the user's region rather than scoring with missing inputs.
Retrieval techniques
| Technique | Strength | Weakness | Typical use |
|---|---|---|---|
| Item-to-item co-occurrence | Simple, explainable, strong baseline | Cold start for new items | "People who watched X also watched" |
| Matrix factorization | Captures latent taste | Retraining lag; weak with side features | Classic collaborative filtering |
| Two-tower embeddings plus ANN | Uses rich features, scales to billions | Needs careful negative sampling | Modern retrieval at YouTube, Pinterest and others |
| Geo plus filters (cells, age, preferences) | Hard constraints satisfied up front | Sparse areas return few candidates | Dating apps, ride and delivery matching |
| Graph-based (friends of friends, random walks) | Strong social signal | Expensive to compute online | People you may know |
Two-sided matching notes
- Dating and marketplace matching must balance attention: very popular profiles should not receive all impressions, so systems cap exposure and boost mutual-interest likelihood rather than one-sided attractiveness.
- Tinder stated in 2019 that it no longer relies on its old Elo-style desirability score, moving to models that weigh mutual activity and preferences.