❤️ Design Tinder — System Design Interview Guide

Medium · Matching & Geospatial

Design a swipe-based dating app like Tinder where users are shown profiles of nearby people, can swipe right (like) or left (pass), and are matched when both swipe right.

Open the interactive Tinder design on PrepGrind → Drag load balancers, caches, databases, and queues onto a canvas, run a live traffic simulation to watch latency and bottlenecks under load, and follow the full interview walkthrough below — free, in your browser.

Functional requirements

Users create a profile with photos and bio
Show a swipe deck: profiles of nearby users meeting age/gender filters
Swipe right to like, left to pass
Instant match notification when both users like each other
In-app chat unlocked after mutual match
Premium: unlimited likes, see who liked you, Boost (top of deck)

Non-functional requirements & scale

75M DAU; 1.6B swipes per day (~18,500 swipes/sec)
No user shown to same person twice (in same session)
Recommendation deck must reflect real-time location (within 50km)
Match notification latency < 1 second
Profile photos served from CDN < 200ms
Swipes must be durable — no lost likes

Capacity estimation

75M DAU, 1.6B swipes/day. Each swipe = write to swipe DB + check for mutual match. Recommendation: geo query for nearby users filtered by age/gender + exclude already-seen. At 18,500 swipes/sec, match check must be fast (Redis set lookup).

Core entities

User — userId, bio, photos[], dob, gender, location (lat/lng), preferences, isPremium
Swipe — swiperId, swipeeId, direction (like|pass), timestamp
Match — matchId, user1Id, user2Id, matchedAt, chatId
UserLocation — userId, lat, lng, updatedAt (updated when app opened)

API design

GET /api/v1/recommendations?limit=10 — Get swipe deck. Returns 10 nearby profiles not yet seen.
POST /api/v1/swipes — Record swipe. Body: { targetUserId, direction }. Returns { isMatch, matchId? }.
GET /api/v1/matches — List all matches with last message preview.
PUT /api/v1/users/me/location — Update user location. Called on app open.

High-level design

Location stored in Redis GEO. Recommendation: GEORADIUS → filter by preferences → exclude seen (Redis SET) → return deck. Swipe: write to Swipe DB + check Redis SET for reverse like → if match, create Match record + notify both.

Deep dives

🎯 Recommendation Algorithm

Step 1: GEORADIUS(lat, lng, 50km) → candidate user IDs. Step 2: Filter by age, gender preferences. Step 3: SMEMBERS seen:userId → exclude already-seen. Step 4: Score remaining candidates by distance, activity recency, mutual friends. Return top 10. Cache recommendation deck in Redis for 1h (pre-compute for active users).

💘 Match Detection

On right swipe: SADD likes:targetId swiperId. Check SISMEMBER likes:swiperId targetId. If true → mutual like detected! Create Match in MySQL, delete both like entries (cleanup), send push notifications to both users, create chat channel. Use Redis Lua script for atomic check-and-create to prevent race conditions.

🌍 Location Privacy

Never expose exact coordinates to other users. Show only distance ("2 km away"). Store lat/lng in Redis GEO, not in user profile. Update location only when user actively opens app. iOS/Android background location is optional. Obfuscate location to nearest 500m before storing to prevent triangulation attacks.

📸 Photo CDN

Photos uploaded to S3. Lambda resizes to 4 variants (thumbnail/small/medium/large). CDN edge serves based on device. Moderation: ML model scans photos on upload (nudity/face detection). Human review queue for flagged content. Photo ranked by "elo" score — higher engagement photos shown first in deck.

Scaling considerations

Redis GEO sharded by geohash cell for geographic partitioning
Cassandra for swipe history (write-heavy, 18K/sec); never updated after insert
Seen-user set per user in Redis: SADD with TTL 7 days (after 7 days, show again)
CDN absorbs 80%+ of photo traffic; critical for p99 < 200ms
Separate premium service tier with higher priority queue for Boost feature

What interviewers expect by level

Junior: Describe swipe flow, match detection, profile retrieval. Understand basic geospatial proximity.
Mid: Redis GEO for locations, SET for seen/likes, match detection with atomic check, CDN for photos.
Senior: Recommendation algorithm with scoring, geosharding, privacy-preserving location, photo processing pipeline.
Staff: Global infrastructure with regional isolation (data residency), ML-based matching score, cost per swipe optimization.

Practice more system design case studies

PrepGrind runs entirely in your browser, free, no installation required. Loading the interactive playground…