</> MAANG.io
system design · 301

Advanced

Master system design interviews with scalable architecture patterns, distributed systems, and real-world design challenges.

0/480 solved 0% complete

Section 8: How Marco Became Card Twelve - Deep Dive: The Recommendation Deck

Executive Summary: The swipe is the cheapest operation in the system. The expensive part is deciding who Priya sees at all. This section walks one refill end to end: geosharded retrieval of 1,000 candidates, a reciprocal filter, seen and block exclusion, ranking for mutual interest, and an attention budget that rations the most-liked profiles. The 50 winners go into a precomputed queue that is checked again at serve time. We finish with how Marco became card 12, and why he wasn't card 1.

Section 7's walls were about correctness. The interviewer now points at the box labelled "Recs" and asks the harder question:

Interviewer: "Priya opened the app at 8:40 and Marco was card 12. Why Marco, and why twelve?"

You: "This is the subsystem I'd worry about most, because it's wrong in silence. A slow swipe pages someone. A bad deck just means fewer matches, and nobody gets paged. It's also two-sided, local, fairness-sensitive, and where nearly all the compute goes: about 1.4 million candidate scorings a second at peak."

One Refill, Five Stages

A refill runs when Priya's server-side queue drops below 20 cards. That happens about 460 times a second on average and about 1.4K times a second at peak, all off the user path, with a p99 budget under 1 second. Her 8:40 deck was built earlier that evening and was already waiting.

One refill, five stages: triggered when the deck queue drops below 20, it retrieves ~1,000 from the geo index, applies the reciprocal filter, excludes seen, blocked and matched, scores cheaply then with a heavy model, re-ranks for attention and writes 50, then re-validates at serve time

  1. Retrieve. The geo index returns about 1,000 candidates: within her 15 miles, men aged 27 to 35, recently active.
  2. Reciprocal filter. In the same query, the candidate's preferences have to fit Priya too. Her age, 29, must be inside their age range, "women" must be in their interested-in list, and she must be within their maximum distance.
  3. Exclude. Drop anyone in her seen-set Bloom filter (Section 7: about 11 KB, fetched once per refill and checked locally), anyone she has blocked or who has blocked her, anyone she has already matched or unmatched, and anyone already in deck:{Priya} or in served:{Priya}.
  4. Rank for mutual interest, in two stages.
  5. Attention budget re-rank, then write the top 50 to deck:{Priya} with a 24-hour TTL.

If Priya lived in a small town and had already swiped through most of those 1,000 candidates, the refill would come back thin. Then it widens the radius, up to the maximum she has agreed to, or pages the retrieval for the next 1,000, so the deck never empties silently.

Interviewer: "Why filter on their preferences? Priya wants who she wants."

You: "Because a one-way filter wastes likes. If a man only wants women aged 22 to 26, Priya can like him all she wants and it will never become a match. She spends a like from her cap of 100 per 12 hours, while his own deck, filtered by his preferences, never shows her at all. Filtering both ways is the cheapest quality gain in the pipeline: it's one more predicate in the query."

Quick check before moving on:

Sign in to continue reading

The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.

Sign in to read the full lesson

Sign in to MAANG.io

Use your Google or Microsoft account — no password to remember.

Continue with Google Continue with Microsoft

Please accept the terms above to continue.