Practice/Uber/Design a Dating App Like Tinder

Design a Dating App Like Tinder

System DesignMust

Problem Statement

Design a dating application that allows users to swipe on profiles, match with other users, receive match notifications, and get location-based recommendations while ensuring disliked profiles are excluded from future suggestions. The core loop is a low-latency, personalized, geo-aware feed with strict exclusion of profiles a user has already passed on.

The system must handle millions of concurrent users generating high-volume swipe events, geospatial indexing for location-based profile discovery, consistency on reciprocal actions (two users liking each other), and real-time notifications on match formation. Peak usage during evening hours creates bursty traffic patterns that the system must absorb without degrading the user experience.

Interviewers at Uber ask this to test your ability to design a high-write, low-latency system with geospatial indexing, consistency on reciprocal actions, 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 actions -- users swipe like or pass on nearby profiles with decisions consistently recorded
Recommendations feed -- users see a location-based feed of profiles tailored to their preferences (age range, distance, gender)
Match notifications -- users see their matches and are notified promptly when a mutual like occurs
Exclusion enforcement -- users are never shown profiles they have already passed on or already decided on

Non-Functional

Scalability -- support tens of millions of daily active users with thousands of swipes per second at peak
Reliability -- ensure swipe decisions are never lost and match detection is accurate
Latency -- serve the recommendations feed in under 200 ms; match notifications delivered within 2 seconds
Consistency -- strong consistency for swipe recording and match detection; eventual consistency acceptable for recommendation feed freshness

What Interviewers Focus On

Based on real interview experiences at Uber and Amazon, these are the areas interviewers probe most deeply:

1. Geospatial Candidate Discovery

Finding nearby profiles that match preferences while excluding previously seen profiles is the core read-path challenge. Interviewers want to see efficient spatial querying without full table scans.

Hints to consider:

Index user profiles by geohash or S2 cells for efficient spatial queries (find users within N km)
Pre-filter candidates by preferences (age, gender) using composite indexes or materialized views
Maintain per-user exclusion sets (already swiped) in Redis to filter candidates before returning results
Consider Bloom filters for large exclusion sets to reduce memory while accepting a small false-positive rate

2. Swipe Processing and Match Detection

When a user swipes right, the system must check if the other user already liked them (match detection). This creates a distributed coordination challenge with high write volume.

Hints to consider:

Store swipe decisions in a durable store (Cassandra) partitioned by swiper_id for fast writes
On a right swipe, atomically check if the reverse swipe exists and create a match record if it does
Use Kafka to decouple swipe ingestion from match detection and notification delivery
Implement idempotency on swipe writes to handle client retries without creating duplicate entries

3. Recommendation Feed Pre-computation

Computing candidates on every request is too slow. Interviewers look for pre-computation and caching strategies that keep the feed fresh and fast.

Hints to consider:

Pre-compute batches of candidate profiles per user, stored in Redis sorted sets scored by relevance
When a user opens the app, serve from the pre-computed batch; trigger background refresh when the batch runs low
Factor in recency, distance, and engagement signals when scoring candidates
Invalidate or adjust candidate batches when a user changes location significantly or updates preferences

4. Real-Time Match Notification

Match formation should instantly notify both users. Interviewers probe how you push notifications reliably.

Hints to consider:

Publish match events to Kafka, consumed by a notification service that pushes to both users
Use WebSocket connections for in-app push when users are active; fall back to mobile push notifications for offline users
Ensure exactly-once notification delivery using idempotency keys per match event
Update the matches list in real time via the same WebSocket channel

Practice/Uber/Design a Dating App Like Tinder

Design a Dating App Like Tinder

System DesignMust

Problem Statement

Key Requirements

Functional

Swipe actions -- users swipe like or pass on nearby profiles with decisions consistently recorded
Recommendations feed -- users see a location-based feed of profiles tailored to their preferences (age range, distance, gender)
Match notifications -- users see their matches and are notified promptly when a mutual like occurs
Exclusion enforcement -- users are never shown profiles they have already passed on or already decided on

Non-Functional

Scalability -- support tens of millions of daily active users with thousands of swipes per second at peak
Reliability -- ensure swipe decisions are never lost and match detection is accurate
Latency -- serve the recommendations feed in under 200 ms; match notifications delivered within 2 seconds
Consistency -- strong consistency for swipe recording and match detection; eventual consistency acceptable for recommendation feed freshness

What Interviewers Focus On

Based on real interview experiences at Uber and Amazon, these are the areas interviewers probe most deeply:

1. Geospatial Candidate Discovery

Finding nearby profiles that match preferences while excluding previously seen profiles is the core read-path challenge. Interviewers want to see efficient spatial querying without full table scans.

Hints to consider:

Index user profiles by geohash or S2 cells for efficient spatial queries (find users within N km)
Pre-filter candidates by preferences (age, gender) using composite indexes or materialized views
Maintain per-user exclusion sets (already swiped) in Redis to filter candidates before returning results
Consider Bloom filters for large exclusion sets to reduce memory while accepting a small false-positive rate

2. Swipe Processing and Match Detection

When a user swipes right, the system must check if the other user already liked them (match detection). This creates a distributed coordination challenge with high write volume.

Hints to consider:

Store swipe decisions in a durable store (Cassandra) partitioned by swiper_id for fast writes
On a right swipe, atomically check if the reverse swipe exists and create a match record if it does
Use Kafka to decouple swipe ingestion from match detection and notification delivery
Implement idempotency on swipe writes to handle client retries without creating duplicate entries

3. Recommendation Feed Pre-computation

Computing candidates on every request is too slow. Interviewers look for pre-computation and caching strategies that keep the feed fresh and fast.

Hints to consider:

Pre-compute batches of candidate profiles per user, stored in Redis sorted sets scored by relevance
When a user opens the app, serve from the pre-computed batch; trigger background refresh when the batch runs low
Factor in recency, distance, and engagement signals when scoring candidates
Invalidate or adjust candidate batches when a user changes location significantly or updates preferences

4. Real-Time Match Notification

Match formation should instantly notify both users. Interviewers probe how you push notifications reliably.

Hints to consider:

Publish match events to Kafka, consumed by a notification service that pushes to both users
Use WebSocket connections for in-app push when users are active; fall back to mobile push notifications for offline users
Ensure exactly-once notification delivery using idempotency keys per match event
Update the matches list in real time via the same WebSocket channel