System Design Interview
Dating app inspired by Tinder and Hinge: geohash-indexed discovery, a write-heavy swipe store with single-lookup mutual-like checks, matches created once per pair, precomputed ranked decks, chat only after a match, and photo moderation. A teaching design.
See why scanning every profile for each deck can't work beyond one city.
What was missing: Nothing yet.
Why that's risky: Each deck scans the whole profile table, swipes (the most frequent action) all hit one database, and two people liking each other at the same moment can create two matches.
What gets added: One server computing the distance to every profile for each deck and storing swipes as rows.
Trade-offs: Simple SQL, but cost grows with every new user.
Find nearby candidates fast, absorb swipes, and create each match exactly once.
What was missing: Discovery scanned every profile and matches could be duplicated.
Why that's risky: Decks are just nearby people in arbitrary order, so everyone sees the same few popular profiles.
What gets added: A geo index of active profiles by geohash cell, a discovery service that builds decks from nearby cells (minus people already swiped), a write-heavy swipe store partitioned by swiper where 'did they like me back?' is a single lookup, a match DB that creates each match once per pair, and photos on a CDN.
Trade-offs: Geohash cells are approximate circles; candidates are filtered by exact distance after lookup.
Show each person candidates they're likely to match with, instantly.
What was missing: Decks weren't ranked.
Why that's risky: Matches can't talk to each other yet.
What gets added: A swipe event stream and a deck builder that precomputes ranked decks for active people, scoring candidates by how likely both are to like each other; decks are served from a cache and refilled as they're used.
Trade-offs: Precomputed decks can be minutes old; someone who just joined appears in others' decks on the next refill.
Let matched people message in real time, and only them.
What was missing: No messaging.
Why that's risky: Unsafe photos and bots aren't caught, and nothing limits mass-liking.
What gets added: Chat gateways that hold connections and deliver messages between matched people, checking the match before allowing a conversation, and a message store partitioned by match.
Trade-offs: Chats are kept per match and deleted if either person unmatches.
Keep the platform safe and watch its health.
What was missing: No moderation, no swipe or message limits, no monitoring.
Why that's risky: Remaining risk is regional: profiles and matches should be replicated across regions.
What gets added: A moderation queue where new photos are checked by classifiers and reported profiles are reviewed, an abuse throttle on swipes and messages per account and device, and monitoring of deck latency, match rate and moderation backlog.
Trade-offs: New photos are briefly pending until checked.
Maintain per-user exposure logs with TTL; incorporate into candidate generation; keep it in a fast store (cache/kv) and periodically compact.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
