Design a Dating App Like Tinder
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.
Asked at:
Uber
A dating app like Tinder is a location-based discovery service 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 passed 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.
Hello Interview Problem Breakdown
Design Tinder
System design answer key for designing a dating application like Tinder, built by FAANG managers and staff engineers.
Common Functional Requirements
Most candidates end up covering this set of core functionalities
Users should be able to swipe like or pass on nearby profiles and have those decisions be consistently recorded.
Users should be able to see a location-based recommendations feed tailored to their preferences.
Users should be able to see a list of their matches and be notified promptly when a mutual like occurs.
Users should not be shown profiles they have already passed on or already decided on in the past.
Common Deep Dives
Common follow-up questions interviewers like to ask for this question
In a swipe-driven app, the write path is hot and highly concurrent. Consistency errors (duplicate swipes, lost updates) lead to bad UX like ghost matches or resurfacing profiles. Interviewers look for idempotency, ordering, and contention strategies in a system design interview at Meta or Uber. - Use idempotency keys: derive a deterministic key from (swiperId, targetId, decision) and write with conditional updates (CAS/IF NOT EXISTS) so retries don't create duplicates. - Append swipes to an immutable event log (e.g., Kafka) and compute matches by joining reciprocal likes; design for at-least-once processing with deduplication on consumer state rather than assuming exactly-once. - Keep a per-user "decisions" index in Redis (e.g., a set or sorted set) for fast checks before enqueueing; reconcile periodically against the source of truth to repair drift.
Feed latency and relevance drive engagement. You need to fetch nearby candidates, filter out exclusions at scale, and rank within a tight SLO (~200 ms). The tricky part is geo indexing plus maintaining large exclusion sets efficiently. - Partition users by geohash/H3 cells and fetch from adjacent cells; pre-segment by basic prefs (age range, gender) so you avoid heavy filtering on the hot path. - Maintain an exclusion filter per user (Redis set plus a Bloom filter) containing disliked, already-liked, and matched IDs; apply it before ranking to keep the feed clean. - Precompute/prefetch small candidate pages asynchronously and cache them per user with short TTL; on request, serve from cache and backfill the next page in the background.
Matches are the delight moment; missed or duplicated notifications erode trust. You need a resilient fan-out mechanism that handles mobile disconnects and ensures at-least-once delivery without spamming users. - Publish match events to a notifications service via Kafka; store per-user delivery state and idempotency tokens so retries don't duplicate pushes. - Use WebSockets/SSE for in-app updates and APNs/FCM for backgrounded devices; fall back to polling with exponential backoff when connections drop. - Implement at-least-once delivery with server/client dedup and a DLQ for failures; monitor end-to-end notification latency and success rates.
Popularity is skewed: a small set of profiles receives disproportionate swipes. Without protections, hot keys melt your cache or a single partition and cause long tail latencies. - Shard hot keys using salted/bucketed partition keys (e.g., targetId#bucket) and aggregate counts asynchronously to avoid single-partition bottlenecks. - Rate limit fan-in and queue writes through Kafka to smooth bursts; apply per-key load shedding when SLOs are threatened. - Cache target profile data aggressively in Redis with short TTL and co-locate data/compute with traffic regions; pre-warm caches for featured users.
Relevant Patterns
Relevant patterns that you should know for this question
Match formation should instantly update both users’ UIs and trigger push notifications. Real-time updates (WebSockets/SSE + push) keep the matches list and unread indicators fresh without wasteful polling.
Swipes and matches create hotspots (celebrity profiles, dense metros). You must avoid hot partitions, enforce idempotency on concurrent writes, and smooth bursts through queues to maintain SLOs.
The recommendations feed is read-heavy and latency-sensitive. Precomputation, caching, and geo-partitioned indices are needed to serve sub-200 ms responses under high QPS.
Relevant Technologies
Relevant technologies that could be used to solve this question
Similar Problems to Practice
Related problems to practice for this question
Both require low-latency, personalized feeds with precomputation, caching, and fan-out/fan-in patterns. Ranking, pagination, and freshness constraints closely mirror a dating recommendations feed.
Both hinge on geospatial discovery and proximity queries. Efficient indexing by location, filtering, and region-based partitioning are central to serving nearby results fast.
While primarily messaging, it shares real-time delivery, mobile push notifications, and presence/connection management patterns that are directly applicable to match notifications and in-app updates.
Red Flags to Avoid
Common mistakes that can sink candidates in an interview
Querying proximity and exclusions on the hot path with full scans or naive SQL filters
This yields high tail latency and poor scalability. Without geospatial indexing and prefiltered candidate sets, each request becomes an expensive scan that will not meet sub-200 ms SLOs.
Relying solely on in-memory caches to hide disliked profiles without a durable source of truth
Cache evictions or restarts will resurface passed profiles, breaking a core requirement. Exclusions must persist in a durable store and be reconciled with caches to ensure correctness across sessions/devices.
Assuming exactly-once processing and ignoring idempotency for swipe writes and notifications
Networks and retries happen; without idempotency keys and deduplication, you’ll create duplicate swipes, incorrect matches, or duplicate notifications that damage user trust and data integrity.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late February, 2025
Uber
Mid-level
Mid February, 2025
Uber
Mid-level
Functionality: 1) Display Users' Matches 2) Send Notifications to Users When They Match 3) Don't Show Disliked Profiles to a User Constraints: 1) Consistent Swipes 2) Location-Based Recommendation/Feed
Your account is free and you can post anonymously if you choose.