MSD0025 Dating App Match Recommendation

Design the match recommendation system for a dating app like Tinder or Hinge. When a user opens the app, the system must surface a stack of candidate profiles that the user is likely to like and who are also likely to like them back, because a one-sided like is wasted attention.

The system must handle the severe imbalance in activity and desirability (a small fraction of profiles receives most of the likes), respect hard constraints (distance, age, stated preferences), introduce enough novelty to avoid the filter bubble where users see the same type over and over, and balance short-term engagement against long-term retention: a user who gets no matches churns, but so does one who is overwhelmed.

How would you design this system? Cover the candidate generation and ranking funnel, the two-sided reciprocity model, how you handle the popularity imbalance, the exploration strategy, and the online and offline metrics.

Line-art scene: a user in front of a phone showing a stack of profile cards with a question mark, one branch where a sent like is ignored and another where it is returned as a match

The Problem: every card in the stack spends a user’s finite attention, and a like that is never returned buys nothing for either side. The design question is which profiles deserve those thirty slots.

Answer

The design is a four-stage funnel: hard filters cut the global user base to an eligible geo and preference pool, an embedding retrieval stage pulls roughly a thousand candidates, a reciprocal ranker scores each pair by the probability of a mutual like, and a slate builder assembles the actual stack under diversity, exposure, and exploration quotas. Two decisions carry the answer. First, the ranking objective is expected mutual match, p_{uv} \cdot p_{vu}, not one-sided like probability, because a one-sided like is wasted attention on both sides of the market. Second, the system is treated as a two-sided marketplace with a scarce resource (each user’s daily attention and inbox capacity), so popular profiles get exposure caps and under-exposed profiles get guaranteed slots instead of being buried by a pure desirability ranking.

(1) Hard Filters First: distance, age band, gender preference, blocks, and recent-activity recency are non-negotiable constraints applied before any model, shrinking millions of profiles to tens of thousands.
(2) Two-Tower Retrieval: geo-sharded ANN lookup over profile embeddings plus complementary sources (mutual-graph, recently-active, likes-you inbox) returns about a thousand candidates in tens of milliseconds.
(3) Reciprocal Ranker: a shared-encoder model with a forward head and a reverse head predicts both directions and ranks by the calibrated product, so a wildly popular profile who will never swipe back scores below a plausible mutual.
(4) Exposure Allocation: per-profile impression caps, inbox-load damping, and demand-aware discounting spread likes across the tail instead of concentrating them on the top decile.
(5) Slate With Explore Slots: the stack is built as a slate, not a top-k list, with quotas for diverse archetypes, uncertain pairs, and new users, which is also how the system escapes the filter bubble.
(6) Retention-Aligned Objective: the training label mix and slate quotas are tuned against day-7 and day-28 retention and conversation rate, not swipe volume.

Pipeline diagram: eligible pool after hard filters, two-tower retrieval, reciprocal ranker, slate builder with caps and exploration, served card stack, with swipe logs feeding training back into retrieval and ranking

Figure 1: The funnel: filters remove the impossible, retrieval proposes, the reciprocal ranker scores both directions, and the slate builder decides what the user actually sees.

Clarify Before Designing:
(1) Scale And Density: how many daily active users, and how dense is a typical market (a dense city with 50k eligible profiles behaves nothing like a rural area with 300)?
(2) Product Grammar: is it a fast swipe stack (Tinder style, roughly 100 cards per session) or a small curated set (Hinge style, a handful per day)? The slate size changes the whole exploration budget.
(3) Success Definition: is the north star matches, conversations that reach a reply, dates, or subscription retention? Optimizing matches alone rewards low-quality likes.
(4) Latency And Precompute: can we precompute a stack asynchronously between sessions, or must every card be scored at request time?
(5) Fairness And Policy Constraints: which attributes may the ranker use, what exposure floor do we owe new or low-activity users, and are paid boosts part of the allocation?
(6) Cost Asymmetry: which is worse for retention, a session with zero appealing profiles or an inbox the user cannot keep up with?


Login to view more content


Log in to track your progress

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *