Practice/Amazon/Design a Dating App Like Tinder

Design a Dating App Like Tinder

System DesignMust

Problem Statement

Design a dating application like Tinder where users swipe right (like) or left (pass) on nearby profiles, get notified on mutual likes (matches), and chat only after matching. The core loop is a low-latency, personalized, geo-aware feed with strict exclusion of profiles a user has already acted on.

Interviewers ask this to test your ability to design a high-write, low-latency system with geospatial indexing, consistency on reciprocal actions (two users liking each other), and real-time notifications. They expect you to reason about contention hotspots, idempotency, cache vs source of truth, and a scalable read path for the recommendation feed.

Key Requirements

Functional

• Swipe decisions -- users swipe like or pass on nearby profiles and have those decisions consistently recorded with no duplicates
• Recommendations feed -- users see a location-based recommendations feed tailored to their preferences (age, distance, interests)
• Match notifications -- users see a list of their matches and are notified promptly when a mutual like occurs
• Profile exclusion -- users are never shown profiles they have already passed on or already decided on in the past

Non-Functional

• Scalability -- support tens of millions of users with high-density metro areas generating concentrated swipe traffic
• Reliability -- maintain 99.9% uptime for the swipe and matching paths; never lose a swipe decision or match event
• Latency -- recommendation feed loading under 200ms, swipe recording under 100ms, match notification delivery within seconds
• Consistency -- strong consistency for swipe recording and match detection; eventual consistency for recommendation feed freshness

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Recommendation Feed and Geospatial Indexing

Serving a personalized, location-aware feed with exclusion filtering at low latency is the core product challenge.

Hints to consider:

• Use geospatial indexes (geohash, H3, or Redis GEO commands) to efficiently find candidates within a configurable radius
• Pre-compute candidate pools per user based on preferences and location, refreshing periodically rather than computing on every request
• Maintain exclusion sets (already-swiped profiles) in a fast store with fallback to durable storage for users with large history
• Consider Bloom filters for approximate exclusion checks when exact sets become too large for in-memory storage

2. Swipe Recording and Match Detection

When two users like each other, the system must detect the mutual like and create a match atomically, handling concurrent swipes correctly.

Hints to consider:

• Record each swipe as a write to a durable store partitioned by user ID, checking for the reciprocal swipe in the same transaction or query
• Use conditional writes or compare-and-swap operations to prevent duplicate swipe recordings from retries
• Implement match detection as a synchronous check during the like operation: when user A likes user B, check if B already liked A
• Publish match events to a queue for notification fan-out, decoupling the critical swipe path from notification delivery

3. Contention and Hot Profiles

Celebrity users or very attractive profiles receive disproportionate swipe traffic, creating hot keys and potential bottlenecks.

Hints to consider:

• Partition swipe storage by the swiping user's ID (not the target) to distribute writes evenly
• Use queues to buffer swipe events during traffic spikes, processing them asynchronously while returning optimistic acknowledgment
• Implement rate limiting per user to prevent bot-driven swipe floods from degrading service quality
• Consider separate handling for "popular" profiles with caching strategies that reduce database contention

4. Real-Time Notifications and Chat

Match formation should instantly update both users and trigger push notifications, and matched users need reliable messaging.

Hints to consider:

• Use WebSocket or Server-Sent Events connections for real-time match notifications and unread indicators
• Implement a pub-sub layer for match event fan-out to connected clients across multiple gateway servers
• Design the chat system as a separate service triggered by match creation, with message persistence and delivery receipts
• Handle offline users by queuing notifications for delivery on next connection with appropriate deduplication

Suggested Approach

Step 1: Clarify Requirements

Confirm scope with the interviewer. Ask about expected user count and geographic distribution, whether the system needs to support multiple dating preferences, if photo/video verification is in scope, and whether group features or events are required. Clarify the matching algorithm complexity: is it simple mutual-like or does it involve scoring and ranking? Establish whether chat functionality is in scope or just the matching portion.