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).