Design a Dating App (Tinder)

1Requirements

2Back-of-envelope estimation

3API design

4High-level design

Clients talk to an API gateway that fronts three main services: a Feed service, a Swipe service, and a Match/Chat service. User profiles live in a Postgres cluster sharded by user id, with a read-through cache for hot profiles.

The Feed service answers the question: which nearby, preference-compatible users has this person not yet swiped on. It queries a geo index (Redis with geohash-bucketed sets, or PostGIS for the MVP) to get candidates within the radius, filters by age and gender preferences, then removes already-swiped ids using a per-user Bloom filter plus an exact check on the swipes table for the survivors. Surviving candidates are ranked by a score (recency of activity, profile completeness, ELO-style desirability) and returned in batches of 25.

The Swipe service is write-optimized. Each swipe is appended to a swipes table sharded by swiper id and, when the direction is a like, the service performs mutual-like detection: check whether the target has already liked the swiper. Doing this check and the match insert in one transaction on a single shard keyed by the unordered user pair guarantees exactly-once match creation even when both users like each other simultaneously.

When a match is created, an event is published to a message queue. Consumers create the chat thread, send push notifications to both users, and update each user's match list cache. Chat itself is a standard messaging subsystem: messages persisted to a table partitioned by match id, fanned out over WebSockets when both users are online.

Swiped-on ids per user grow unboundedly, so the dedup layer is tiered: a Bloom filter in Redis (fast, tiny, false positives acceptable because a false positive only hides one candidate) backed by the authoritative swipes table. Feeds are also precomputed asynchronously for active users so the read path is mostly a cache pop.

5Data model

6Deep dives

7Rapid implementation: build the MVP

Theory is table stakes. Here is how you would stand up a working version fast, on a budget, with the core algorithm in real code.

1. 01Scaffold a Next.js app with Supabase auth; create users, swipes, matches, messages tables and enable the PostGIS extension.
2. 02Build the profile screen: photo upload to Supabase storage, bio, preferences; store location as a PostGIS geography point captured from the browser geolocation API.
3. 03Implement GET /api/feed: one SQL query with ST_DWithin for radius, preference filters both directions, and NOT EXISTS against swipes (fine at MVP scale).
4. 04Implement POST /api/swipes as a single Postgres transaction that inserts the swipe, checks the reverse like, and inserts the match row on a unique pair constraint.
5. 05Build the swipe UI: a card stack with drag gestures (framer-motion), calling the swipe endpoint optimistically.
6. 06Build the matches list and a simple chat using Supabase Realtime channels per match id.
7. 07Add the unique index on matches(least_id, greatest_id) and write a two-browser test: like from both sides, assert exactly one match row and both clients notified.

BEGIN;

INSERT INTO swipes (swiper_id, target_id, direction)
VALUES (:me, :them, 'like')
ON CONFLICT (swiper_id, target_id) DO NOTHING;

-- Create the match only if the reverse like exists.
-- The unique index on (user_a_id, user_b_id) makes a racing
-- duplicate insert a no-op instead of a second match.
INSERT INTO matches (user_a_id, user_b_id)
SELECT LEAST(:me, :them), GREATEST(:me, :them)
WHERE EXISTS (
  SELECT 1 FROM swipes
  WHERE swiper_id = :them AND target_id = :me
    AND direction = 'like'
)
ON CONFLICT (user_a_id, user_b_id) DO NOTHING
RETURNING match_id;

COMMIT;
-- If RETURNING yields a row, respond matched: true.

SELECT u.user_id, u.name, u.bio, u.photos_json,
       ROUND(ST_Distance(u.location, me.location) / 1000) AS km_away
FROM users u, users me
WHERE me.user_id = :me
  AND u.user_id <> :me
  AND ST_DWithin(u.location, me.location, me.pref_radius_km * 1000)
  -- my preferences about them
  AND date_part('year', age(u.birth_date)) BETWEEN me.pref_min_age AND me.pref_max_age
  AND u.gender = ANY (me.pref_genders)
  -- their preferences about me (both directions!)
  AND date_part('year', age(me.birth_date)) BETWEEN u.pref_min_age AND u.pref_max_age
  AND me.gender = ANY (u.pref_genders)
  AND NOT EXISTS (
    SELECT 1 FROM swipes s
    WHERE s.swiper_id = :me AND s.target_id = u.user_id
  )
ORDER BY u.last_active_at DESC
LIMIT 25;

import { Redis } from "ioredis";
const redis = new Redis(process.env.REDIS_URL as string);

// KEYS[1] = likes set for the normalized pair
// ARGV[1] = liker id. Returns 1 when both sides have liked.
const LUA =
  "redis.call('SADD', KEYS[1], ARGV[1]) " +
  "if redis.call('SCARD', KEYS[1]) >= 2 then return 1 end " +
  "return 0";

export async function recordLike(me: string, them: string): Promise<boolean> {
  const [a, b] = [me, them].sort();
  const key = "pairlikes:" + a + ":" + b;
  const matched = (await redis.eval(LUA, 1, key, me)) === 1;
  if (matched) {
    // enqueue durable match creation; Redis decided the race
    await redis.lpush("match_events", JSON.stringify({ a, b, at: Date.now() }));
  }
  return matched;
}