Design Swipe Matching

You open a dating app and see one face at a time. Swipe right if you are interested, left if not. When two people have both swiped right on each other, the app says "It's a match" and opens a chat. A swipe-based dating app such as Tinder is the kind of product this question means.

Each piece looks trivial: a swipe is an insert, a match is a lookup, the stack is a query. At tens of thousands of swipes a second, the inserts need a write-optimised store, the lookup has a race when two people swipe together, and the stack must never repeat someone. The steps follow A Framework for Any Design. Try each "Your turn" box before reading on.

#Clarify the problem

• Functional: create a profile with photos and preferences (age range, genders, maximum distance); get a stack of candidates who fit my preferences and whose preferences fit me; swipe left or right; match when both swipe right; list my matches.
• Non-functional: a swipe returns in under 200 ms; every mutual right swipe produces exactly one match; a profile is never shown twice to the same person; stacks may be minutes stale; right swipes are durable, a lost left swipe is tolerable.
• Out of scope: chat (see Design a Chat App), payments, photo moderation, the ranking model itself.

#Estimate the scale

• Swipes: 20 million × 100 = 2 billion a day ÷ 86,400 ≈ 23,000 a second. With an evening peak of 3x, about 70,000 a second.
• Right swipes: if 30% are right, about 21,000 a second at peak. These are the ones that can create a match.
• Swipe history: about 50 bytes stored per swipe, so 2 × 10⁹ × 50 B = 100 GB a day, about 36.5 TB a year.
• Profiles: 100 million accounts × 2 KB = 200 GB, plus photos in blob storage behind a CDN.
• Stacks: 200 candidate ids of 8 bytes per daily user is 20 × 10⁶ × 1.6 KB = 32 GB of cache. The daily users' profile cards add 20 × 10⁶ × 2 KB = 40 GB.

#Define the API

PUT  /me/profile          name, photos, bio, age range, genders wanted, max distance
PUT  /me/location         { "lat": 51.51, "lng": -0.12 }   sent when the app opens
 
GET  /stack?count=20
  200 { "profiles": [ { "user_id": "u_91", "name": "Ben", "age": 31,
                        "distance_km": 4, "photos": [...] }, ... ] }
 
POST /swipes
  body: { "target_id": "u_91", "direction": "right" }
  200 { "matched": true, "match_id": "u_12:u_91" }
  200 { "matched": false }
  404 Not Found     target deleted their account
 
GET  /matches?cursor=...

The decision worth arguing is what the stack does not include: whether each candidate already liked you. Sending it would let the app show "It's a match" with no round trip, but anyone inspecting the app's traffic could list everyone who liked them. Keep it on the server and answer in the swipe response; under 200 ms is fast enough for the animation.

The swipe is idempotent by (swiper, target): swiping on the same person twice, or a retry after a timeout, returns the same result. See idempotency and retries.

#Model the data

profiles                       -- relational, 200 GB
  user_id PK, name, birth_date, gender, bio, photo_urls,
  age_min, age_max, genders_wanted, max_distance_km,
  lat, lng, last_active_at
 
swipes                         -- wide-column, partition key swiper_id
  swiper_id, target_id, direction, created_at
  PRIMARY KEY ((swiper_id), target_id)    -- 2 billion rows a day
 
pair_likes                     -- sharded relational, key = the pair
  low_id, high_id              -- the two user ids, smaller first
  low_likes_high  BOOLEAN
  high_likes_low  BOOLEAN
  matched_at      TIMESTAMP NULL
  PRIMARY KEY (low_id, high_id)

The swipe history is append-only, write-heavy and read by one key, the swiper, which fits a wide-column store such as Cassandra: writes land in memory and a log, so 70,000 a second spread over a cluster is routine. The pair row needs a different guarantee, an atomic read-modify-write on one key, so it lives in a store that offers that: sharded relational rows, or a key-value store with conditional updates. It grows by up to 600 million rows a day (30% of 2 billion swipes), about 9 TB a year at 40 bytes a row, so shard it by a hash of the pair. Profiles are ordinary relational data, the source for two copies fed by its change stream (not drawn below): profile cards in the cache, and a search index with a geo field for stack building.

#High-level design

Stacks are built ahead of time, so opening the app is a cache read. Swipes go to the history for "seen" and to the pair row for "matched".

Step through Ana getting her stack and swiping, then Ben swiping on her 3 ms later.

#Deep dives

Interviewers push on the swipe rate, detecting the match exactly once, building the stack, and never repeating a profile.

#Recording 70,000 swipes a second

Each swipe is a tiny append. The only read is "all swipes by this user", to rebuild a seen filter. Partition the history by swiper_id and cluster by target_id inside the partition, so a repeated swipe overwrites the same cell instead of adding a row. In a log-structured store (see indexing), each write is an append to memory and a commit log, which is why such stores take this rate on modest hardware.

Left swipes are 70% of the volume and only feed the seen filter, so one replica's acknowledgement is enough, and they may expire after a year if the product wants people to reappear. Right swipes are written with a quorum. Partitions stay small: 100 swipes a day is 36,500 a year, under 2 MB.

#Detecting a match exactly once

Ana and Ben swipe right on each other 3 ms apart. The obvious method writes "Ana likes Ben" under Ana's key, then reads "does Ben like Ana?" under Ben's key. Each request writes then reads. If the reads go to replicas that lag, both can read before the other's write arrives, and neither announces a match. If both reads see the other write, both announce one.

-- Ana is user 12, Ben is user 91: low_id = 12, high_id = 91
INSERT INTO pair_likes (low_id, high_id, low_likes_high, high_likes_low)
     VALUES (12, 91, false, true)
ON CONFLICT (low_id, high_id) DO UPDATE
   SET high_likes_low = true,
       matched_at = CASE WHEN pair_likes.low_likes_high
                         AND pair_likes.matched_at IS NULL
                         THEN now() ELSE pair_likes.matched_at END
RETURNING matched_at;    -- not null: tell Ben "It's a match"

Why it is exact: the database runs the two updates on the row one after the other. The first sees only its own flag; the second sees both and sets matched_at. The match is decided and stored in one atomic write, so it cannot be lost between "detected" and "saved". A retried request finds matched_at already set and returns the same answer. Notifying Ana reads the row's change stream and uses the pair key as the match id, so a redelivered event produces no second match.

#Building the stack

A good candidate is nearby, fits my filters, has me inside theirs, is unseen and recently active. Running that query on every app open is wasteful when the answer barely changes in an hour.

So precompute. The builder runs one query on the search index: a geo filter around my location (the cells and neighbour cells from Design Ride Sharing), plus age, gender, the other person's age range and genders, and active in the last 30 days. It then drops seen profiles, checks each candidate's own distance limit, ranks, and stores 200 ids in the cache. The stack service serves 20 at a time and asks for a refill below 50, so a heavy swiper never waits.

The cost is staleness: a profile in my stack may have been deleted since. The stack service checks the 20 it sends against deletions and my seen filter. Rebuild a stack when the user moves more than a few kilometres.

#Never showing a profile twice

The builder must remove everyone I have swiped on from 1,000 candidates. The exact answer is in my swipe history, but that is a large read on every refill.

A Bloom filter answers "definitely not seen" or "probably seen". Its error points the safe way: it can wrongly say "seen", hiding someone, but never wrongly say "not seen". In a small town the cost is real: 1% of 1,000 candidates is 10 people never shown. Say so, and offer the exact set to users with a small pool. When a user passes the item count the filter was sized for, rebuild a larger one from the history, because an overfull filter's false-positive rate climbs fast.

#Bottlenecks and failures

At 10x, 700,000 swipes a second, the history cluster grows by adding nodes, since partitions are per user. The pair store needs more shards for 210,000 right swipes a second; the pair key hashes evenly. A popular profile receiving thousands of right swipes a minute touches thousands of different pair rows, so there is no hot row. The geo index sees only refill load; dense cities need more replicas.

#What a strong answer sounds like

#Follow-up questions

#How would you add a "see who liked you" feature?

Query pair rows where the other flag is set and mine is not. That needs an index by user, so keep a per-user "liked by" list written from the pair rows' change stream. Serve it only to users entitled to it, from the server.

#A user travels to another city. What changes?

The location update moves their profile document in the geo index and discards their stack, so the next refill uses the new place. The seen filter stays.

#How do you stop a few very popular profiles from appearing in every stack?

That is ranking: the builder counts impressions per profile and down-ranks those far above their share.

#A user unmatches. Can they appear again?

No. The swipe stays in the history and the seen filter, and the pair row keeps both flags with an unmatched_at time so a retry cannot recreate the match.

#How would you shard the geo index?

By region, with the maximum distance capped at, say, 100 km so a stack query stays in one region. Big cities get more replicas; a profile near a border goes into both regions' shards.