Tinder System Design

The interviewer's prompt fits on an index card: "Design a dating app like Tinder. People create a profile with photos, and the app shows them a stack of nearby people who fit their preferences. They swipe right to like or left to pass. When two people like each other, it's a match and they can chat. Assume tens of millions of daily users."

The first version writes itself: a users table, a swipes table, a query for "people near me," and a check for "did they like me back?" Now meet Priya, a 29-year-old product designer in Austin. It's Sunday, 8:40 p.m., the busiest hour of the busiest night of the week. She opens the app and expects the first card instantly, with no spinner. She'll swipe about a hundred times in a few minutes, and she must not see a face she has already swiped on. Card 12 is Marco, 31, four miles away, who liked her last Thursday. She swipes right. Within 200 milliseconds her phone says It's a Match, and Marco's phone buzzes a few seconds later. If they had both swiped on each other in the same millisecond, the system still owes them exactly one match: not zero, not two. And nothing in any of this may tell a stranger where Priya lives.

The Trap Built Into "It's Just Swipes"

Two failures come up again and again:

• The CRUD App: one relational database, a SELECT ... WHERE distance < 15 on every card, and a "did they like me?" lookup bolted on afterwards. Signal: never did the arithmetic that turns 20 million daily users into ~70,000 swipe rows a second at peak, never noticed that photos (not swipes) are the bandwidth, and never asked what happens when two likes arrive at once.
• The ML Showcase: spends forty minutes on embeddings and ranking models, while the match (the one moment users actually care about) gets a single arrow and the location field ships exact coordinates to every client. Signal: optimised the part that is easiest to talk about, not the parts that break.

The passing answer sees three systems sharing one swipe. A write firehose that records 2 billion swipes a day and must decide, inside one 200-millisecond call, whether a like completes a match. A read-mostly recommendation pipeline that builds each user's deck of 50 cards ahead of time, from a geosharded index, filtered so both sides fit each other's preferences, ranked for mutual interest, and rationed so the most-liked profiles don't drown. And a trust layer that rounds every distance, keeps every like secret until it's returned, and makes a block take effect everywhere in under a second.