Design Tinder: Building a Geo-Distributed Matching Engine That Won't Swipe Left at 3AM

Everyone thinks Tinder is just a fancy SQL query with a WHERE clause on distance. That's cute. Until your database melts at 2 AM on a Saturday because 10,000 people in Manhattan all swiped right at once. The real challenge isn't matching — it's doing it in under 500 milliseconds while handling 1.8 million swipes per second at peak. This isn't a CRUD app. It's a real-time geo-distributed event system with a side of social graph. By the end of this, you'll know how to build a matching engine that doesn't fall over when a Taylor Swift concert ends.

Why Geo-Sharding Is Non-Negotiable

Your first instinct is to put all user locations in a single Redis sorted set. That works for 100,000 users. At 10 million, every ZRANGEBYSCORE takes 500ms. At 100 million, your Redis instance runs out of memory and starts evicting keys. The fix is geo-sharding: partition your data by geohash cells. Each cell holds a manageable number of users. Queries only hit the relevant cells. This is the difference between a system that scales and a system that burns.

// io.thecodeforge — System Design tutorial

// Geo-shard key design for Tinder's matching service
// Each geohash prefix (5 chars) defines a cell ~4.9km x 4.9km
// Key: location:{geohash5}
// Value: Redis sorted set with member = user_id, score = unix_timestamp

// When a user swipes, we:
// 1. Compute geohash5 of user's location
// 2. Add to sorted set: ZADD location:dr5ru 1625097600 user:12345
// 3. For potential matches, query neighboring cells (8 neighbors)
// 4. ZRANGEBYSCORE on each cell with limit 100
// 5. Merge results, filter by distance, return top 50

// This keeps each sorted set under 10k members in dense areas.

The Matching Pipeline: From Swipe to Match in Under 500ms

When user A swipes right on user B, you need to check if B already swiped right on A. That's a join across two databases: the swipe event log and the user profile. Doing this synchronously kills latency. Instead, use an event-driven pipeline. Swipe right → Kafka event → consumer updates Redis set of 'right swipes' for each user. When a match is detected (both swiped right), another event triggers the match notification. This decouples the write path from the read path and keeps latency predictable.

// io.thecodeforge — System Design tutorial

// Kafka topic: swipe_events
// Partition key: user_id (so all swipes for a user go to same partition)
// Consumer logic:
// 1. Read swipe event: {swiper: A, swipee: B, direction: right}
// 2. Redis: SADD swipes:A B  (set of users A swiped right on)
// 3. Redis: SISMEMBER swipes:B A  (did B swipe right on A?)
// 4. If yes, publish to match_events topic: {user1: A, user2: B, timestamp}
// 5. Match consumer sends push notification, updates Cassandra

// This avoids a synchronous cross-database query.

Why Cassandra Beats PostgreSQL for User Profiles

PostgreSQL with PostGIS can do geo queries. But at Tinder's scale, you need write throughput that PostgreSQL can't handle without sharding. Cassandra gives you linear write scalability and tunable consistency. Use eventual consistency for profile reads (you can tolerate seeing a slightly outdated bio). Use quorum consistency for match writes (you can't afford to lose a match). The trade-off: no joins, no complex queries. You design your schema around query patterns.

// io.thecodeforge — System Design tutorial

// Cassandra schema for user profiles
// Partition key: user_id (UUID)
// Clustering columns: none (each user is a single row)

CREATE TABLE user_profiles (
    user_id UUID PRIMARY KEY,
    name text,
    age int,
    bio text,
    photos list<text>,
    last_location text,  // geohash5
    preferences map<text, text>,
    updated_at timestamp
) WITH compaction = { 'class': 'LeveledCompactionStrategy' };

// For geo queries, we use Redis, not Cassandra.
// Cassandra is the source of truth for profile data.

// Write path: user updates profile → write to Cassandra with QUORUM
// Read path: when showing a profile, read from Cassandra with ONE (eventual consistency)

The Swipe Queue: Rate Limiting and Backpressure

Without rate limiting, a viral user can get 10k swipes per second, overwhelming your Redis cluster. Implement a token bucket per user for outgoing swipes. Also, use a bounded queue (e.g., Disruptor) in the swipe service to apply backpressure when downstream systems lag. If the queue fills up, reject new swipes with HTTP 429. Better to drop a swipe than to crash the service.

// io.thecodeforge — System Design tutorial

// Token bucket rate limiter per user
// Redis key: rate_limit:{user_id}
// Fields: tokens (remaining), last_refill (timestamp)

// Refill rate: 10 tokens per second, max bucket 30
// Each swipe consumes 1 token

// Pseudo-code:
function allowSwipe(userId):
    current = redis.hgetall("rate_limit:" + userId)
    now = time.now()
    elapsed = now - current.last_refill
    newTokens = min(30, current.tokens + elapsed * 10)
    if newTokens >= 1:
        redis.hmset("rate_limit:" + userId, {tokens: newTokens - 1, last_refill: now})
        return true
    else:
        return false

// In production, use Lua script for atomicity.

Handling the 'Double Swipe' Race Condition

Two users swipe right on each other at the exact same millisecond. Both consumers check SISMEMBER and see false. Both write to match_events. You get duplicate matches. Fix: use a conditional write in Redis. When writing the swipe, use SETNX to create a lock key. Only proceed if lock acquired. Or use Redis streams with consumer group idempotency. The simplest: make match ID the primary key in Cassandra and use INSERT IF NOT EXISTS.

// io.thecodeforge — System Design tutorial

// Using Redis SETNX to prevent duplicate match creation
// Key: match_lock:{user1}:{user2}  (sorted by user ID to avoid deadlock)
// TTL: 5 seconds

// Consumer logic:
// 1. Compute lockKey = "match_lock:" + min(A,B) + ":" + max(A,B)
// 2. if redis.setnx(lockKey, "1", ttl=5):
// 3.     // Only one consumer gets here
// 4.     if redis.sismember("swipes:" + A, B) and redis.sismember("swipes:" + B, A):
// 5.         cassandra.execute("INSERT INTO matches (id, user1, user2) VALUES (?, ?, ?) IF NOT EXISTS",
// 6.             matchId, A, B)
// 7.     redis.del(lockKey)

// This ensures exactly one match record.

When Not to Use This Architecture

If you're building a dating app for a small town with 10,000 users, don't copy Tinder's architecture. You don't need Kafka, Cassandra, or Redis clusters. A single PostgreSQL instance with PostGIS and a simple swipe table will work fine. The overhead of distributed systems will kill your velocity. Only reach for this when you have millions of users and a 500ms SLA. Otherwise, keep it simple.