Design Tinder: System Design & Architecture

Scope

Back-of-the-Envelope Estimates

• Assume 100M monthly active users, ~20M daily active users, peak ~2M concurrent
• A write is anything that creates or changes data: a swipe, a profile edit, a match. A read fetches without changing: loading the stack, viewing a profile, listing matches
• Swipes: ~600M/day ÷ 86,400 seconds ≈ 7K swipes/sec average; a 10x peak factor gives ~70K/sec. Each swipe is one tiny write plus one point-read (checking whether the other person already liked you)
• Discovery reads: ~10 profile cards viewed per swipe → ~6B card views/day, but cards are delivered in stacks of ~25 per request → ~240M stack requests/day ≈ 2.8K/sec average, ~28K/sec peak
• Matches: only a small fraction of right swipes are mutual → a few million matches/day, thousands of times rarer than swipes. Rare + must-be-exact is a very different storage problem than frequent + tolerant
• Storage: a swipe row is ~50 bytes (actor, target, direction, timestamp) → 600M/day x 50B ≈ 30GB/day, ~11TB/year, growing forever because of permanent filtering - swipe history is by far the biggest table. Profiles are ~2KB x 100M = ~200GB total, tiny by comparison
• The shape: the swipe path is a firehose of tiny writes; the discovery path is heavy reads over a small, cacheable dataset. Two different workloads living in one app

Data Model & Storage

• Profiles (PostgreSQL + PostGIS): user_id, name, age, gender, bio, interests[], location (geographic point), max_distance_km, preference filters, last_active. SQL because this is relational reference data with modest writes, and PostGIS gives us the geospatial query the whole discovery path depends on. Read replicas plus a Redis cache absorb the read load.
• Swipes (Cassandra, one row per (actor_id, target_id)): direction and timestamp. Keyed by actor and target so the same swipe written twice just overwrites itself (idempotent), the partition per actor is the user's full swipe history (permanent filtering), and the reverse check "did B like A?" is a single point-read of row (B, A). Written and read at QUORUM so a just-written like is guaranteed visible - the match race depends on it.
• Matches (PostgreSQL): one row per matched pair, stored as (smaller user_id, larger user_id) with a UNIQUE constraint on the pair. SQL because this table is small and rare-write but carries the hard invariant: exactly one match per pair, enforced by the database itself, not by application code being careful.
• Stack Cache (Redis): prebuilt stacks of ~100 candidate cards per active user with a short TTL, so most stack requests never touch PostGIS. Cache only - losing it costs a rebuild, never data.
• Swiped Set (Redis): per-user set of already-swiped target ids for fast permanent filtering during stack builds; heavy swipers get a bloom filter instead (tiny memory, errs in the safe direction - see the low-level design).

API Design

Low-level Design

Database Schemas

- Profiles (PostgreSQL + PostGIS)
  user_id UUID PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  age INT NOT NULL,
  gender gender_enum NOT NULL,
  bio TEXT,
  interests TEXT[],
  photo_urls TEXT[],            -- pointers; upload pipeline out of scope
  location GEOGRAPHY(POINT) NOT NULL,
  max_distance_km INT DEFAULT 25,
  pref_gender gender_enum[],
  pref_age_min INT DEFAULT 18,
  pref_age_max INT DEFAULT 99,
  last_active TIMESTAMP,
  created_at TIMESTAMP DEFAULT NOW(),

  INDEX idx_location ON profiles USING GIST (location)
    -- "everyone within X km" as a tree descent, not a 100M-row scan
  INDEX idx_prefs ON (gender, age)
    -- narrows candidates before the mutual-preference check

- Swipes (Cassandra) -- the firehose: 600M rows/day, append-only
  PRIMARY KEY ((actor_id), target_id)
  Fields: direction ('left' | 'right'), ts
  -- one row per (actor, target): swiping twice overwrites itself (idempotent)
  -- the partition (actor_id) = full swipe history -> permanent filtering
  -- reverse check "did B like A?" = point read of row (B, A)
  -- QUORUM writes + QUORUM reads: a just-written like is always visible,
  --   which is what makes the simultaneous-swipe race safe

- Matches (PostgreSQL) -- small, rare-write, precious
  match_id UUID PRIMARY KEY,
  user_a UUID NOT NULL,   -- always the smaller user_id of the pair
  user_b UUID NOT NULL,   -- always the larger user_id
  created_at TIMESTAMP DEFAULT NOW(),

  UNIQUE (user_a, user_b)
    -- the referee: exactly one match per pair, enforced by the database,
    -- no matter how the concurrent-swipe race interleaves
  INDEX idx_matches_a ON (user_a, created_at DESC)
  INDEX idx_matches_b ON (user_b, created_at DESC)

Redis keys

- Stack cache (prebuilt discovery stacks)
  Key: "stack:{user_id}" -> [candidate cards ...]
  TTL: ~10 minutes; refreshed in the background for active users

- Swiped set (permanent filtering)
  Key: "swiped:{user_id}" -> set of target_ids
  -- heavy swipers switch to a bloom filter: fixed tens-of-KB memory,
  --    "definitely not swiped" / "probably swiped"; errors only hide
  --    an unswiped profile, never resurface a swiped one

- Hot profile cards
  Key: "profile:{user_id}" -> rendered card JSON
  TTL: ~5 minutes; absorbs reads for widely-shown profiles

{
  "name": "Jordan",
  "age": 28,
  "gender": "male",
  "bio": "Software engineer who loves hiking",
  "interests": ["hiking", "coffee", "live music"],
  "location": { "latitude": 37.7749, "longitude": -122.4194 },
  "max_distance_km": 25,
  "preferences": {
    "gender": ["female"],
    "age_min": 24,
    "age_max": 34
  }
}

{
  "user_id": "u_8f3e2d1c",
  "created_at": "2026-07-05T18:04:11Z"
}

{
  "profiles": [
    {
      "user_id": "u_456",
      "name": "Sam",
      "age": 27,
      "bio": "Artist and traveler",
      "photo_urls": ["https://cdn.example.com/p/u_456/1.jpg"],
      "distance_km": 5
    }
  ],
  "count": 25,
  "stack_refreshes_at": "2026-07-05T18:14:00Z"
}

// distance_km is rounded on purpose - exact coordinates and precise
// distances are never exposed (they can be used to triangulate someone's
// location). Every profile here has already passed the mutual-preference
// check and the already-swiped exclusion.

{
  "target_user_id": "u_456",
  "direction": "right"
}

{
  "matched": true,
  "match_id": "m_7a2b8f4e"
}

// Idempotent: retrying this request overwrites the same (actor, target)
// row and returns the same result. If both users swipe right at the same
// moment, both may attempt match creation - the UNIQUE constraint makes
// the second attempt a no-op returning the same match_id, so both clients
// can show "It's a Match" for the same single match.

{
  "matches": [
    {
      "match_id": "m_7a2b8f4e",
      "user": {
        "user_id": "u_456",
        "name": "Sam",
        "photo_urls": ["https://cdn.example.com/p/u_456/1.jpg"]
      },
      "created_at": "2026-07-05T18:05:02Z"
    }
  ],
  "next_cursor": "2026-07-05T18:05:02Z#m_7a2b8f4e",
  "has_more": false
}

// 429 Too Many Requests - swipes are rate limited per user
{
  "error": "rate_limited",
  "message": "Swipe limit reached. Try again later.",
  "retry_after_seconds": 3600
}

// 404 Not Found - profile does not exist or is not visible to the caller
{
  "error": "not_found",
  "message": "Profile not found"
}
// Deleted or out-of-range profiles return the same 404 as nonexistent
// ones, so the API cannot be used to probe who is on the app.

Concluding Discussion

Critical Knowledge