# System Design: Design Tinder — Geolocation Matching, Swipe System, Recommendation, Real-Time Chat, Privacy

Source: https://www.techinterview.org/post/3233474314/system-design-design-tinder-dating-app-geolocation-matching-swipe-recommendation-real-time-chat-profile-photos-privacy/
Updated: 2026-04-20 · techinterview.org

Tinder processes 2+ billion swipes per day across 190+ countries, matching users based on location, preferences, and recommendation algorithms. Designing a dating app tests your understanding of geospatial queries, recommendation systems, real-time matching, and privacy -- a unique combination of system design concepts. This guide covers the architecture from user discovery to match and conversation.

## User Discovery and Geospatial Queries

The core query: "find users near me who match my preferences." This requires: (1) Location indexing -- store user locations in a geospatial index. Redis GEO (GEOADD, GEOSEARCH) or a database with spatial indexing (PostGIS, MongoDB 2dsphere). When a user opens the app, their location is updated. GEOSEARCH finds users within a radius (default 50 km, configurable). (2) Preference filtering -- filter by: age range (user preference), gender (user preference), and distance (sort by proximity). The query: find all active users within 50 km whose age is between 25 and 35 and gender matches my preference and I match their preference (mutual compatibility). (3) Exclusion -- exclude users already swiped (left or right), blocked users, and reported users. Maintain a per-user "seen" set (Redis SET or Bloom filter for space efficiency). For a user who has swiped 10,000 profiles, the exclusion set is large -- a Bloom filter is more memory-efficient than storing all IDs. Active user definition: users who opened the app within the last 7 days. Inactive users are deprioritized or hidden. This keeps the recommendation pool fresh and reduces the chance of matching with someone who will never respond.

## Recommendation and Ranking

Not all potential matches are shown equally. Tinder ranks profiles to maximize engagement (mutual right swipes). Ranking factors: (1) Elo score (legacy) / desirability score -- a score based on how many right swipes a user receives. Users with higher scores are shown to other high-score users first. This creates tiers. (2) Profile completeness -- users with more photos, a bio, and verified accounts are boosted. (3) Activity recency -- recently active users are prioritized (more likely to respond). (4) Mutual compatibility signals -- if User A right-swiped profiles similar to User B profile, B is ranked higher for A. Collaborative filtering on swipe patterns. (5) Distance -- closer users rank higher (more likely to meet in person). (6) Freshness -- newly joined users get a temporary boost ("new user boost") to quickly establish their desirability score and engagement. The recommendation pipeline generates a ranked list of candidates per user. This list is pre-computed periodically (every few hours) and cached. When the user opens the app, the pre-computed list is served with real-time filtering (remove recently swiped profiles). If the list is exhausted, fall back to a broader geographic range or relaxed preferences.

## Swipe and Match System

Swipe processing: when User A swipes right on User B: (1) Record the swipe: store (user_a, user_b, direction=right, timestamp) in a swipe table. (2) Check for mutual match: does User B have a right swipe on User A? Query: SELECT 1 FROM swipes WHERE swiper = B AND swiped = A AND direction = right. If yes: create a match record (match_id, user_a, user_b, created_at). Notify both users immediately (push notification + in-app animation). (3) If no: no notification. User B does not know that A swiped right. Optimization: the match check must be fast (sub-10ms) because it happens on every right swipe. Store recent right swipes in Redis: SET right_swipes:{user_b} containing user IDs who right-swiped B. The match check is SISMEMBER right_swipes:{user_b} user_a -- O(1). Swipe rate limiting: prevent bot behavior. Limit swipes per day (100 for free users, unlimited for premium). Track in Redis with INCR and TTL. Left swipe storage: left swipes need to be stored (to exclude from future recommendations) but are accessed less frequently. Store in a database, cache the exclusion set in a Bloom filter for fast "have I seen this user?" checks.

## Real-Time Chat

After matching, users can chat. The chat system is similar to WhatsApp (covered in our Chat Application guide) but simpler: only 1-to-1 conversations between matched users, no group chat. Architecture: WebSocket connections for real-time message delivery. Messages stored in a database partitioned by match_id. Each message: message_id (time-sorted), match_id, sender_id, text, media_url, created_at, read_at. Delivery: when User A sends a message, the chat service stores it and pushes to B via WebSocket (if online) or push notification (if offline). Read receipts: when B opens the conversation, send a read event that updates read_at for unread messages and notifies A. Media sharing: photos sent in chat are uploaded to S3 via presigned URL, moderated by ML (content policy), and served via CDN. Disappearing messages: some dating apps support ephemeral messages. Set a TTL and delete after the viewing period. Unmatch: if a user unmatches, the conversation is hidden from both sides. Messages are soft-deleted (retained for safety/abuse investigation but not visible to either user).

## Safety and Privacy

Safety is critical for dating apps: (1) Photo verification -- users submit a selfie mimicking a specific pose. ML compares it with profile photos to verify the person is who they claim to be. Verified profiles get a badge. (2) Content moderation -- ML scans uploaded photos for nudity, violence, and policy violations. Reported messages are reviewed. Repeat offenders are banned. (3) Block and report -- users can block (hide each other permanently) and report (trigger a review). Reports include categories: inappropriate messages, fake profile, underage user, harassment. (4) Location privacy -- never expose exact coordinates to other users. Show approximate distance only ("3 km away"). The server performs proximity calculations; client apps never receive other users precise lat/lng. (5) Data privacy -- GDPR compliance: users can download all their data, request deletion (right to be forgotten), and control visibility (hide profile from certain demographics). Swipe data is sensitive -- store securely and delete when the account is deleted. (6) Safety features -- share your date details with a friend (location, time, match profile), panic button that discreetly contacts emergency services, and background checks (some apps integrate third-party background check services).