Problem Statement: A Geo-Spatial Matching Engine at Billion-Swipe Scale
Frames the dating app as a real-time geo-matching and recommendation platform, not merely a profile database.
Problem Statement
Design a location-based dating and matching platform that allows users to create profiles, discover compatible people within a configurable radius, express interest through a swipe gesture, receive real-time match notifications when interest is mutual, and engage in private chat. The system must handle billions of daily swipes, maintain sub-200ms discovery latency, detect matches in real time, power a personalized recommendation feed, and protect user privacy in a domain where data sensitivity is extreme.
This is not a standard CRUD social network. A dating app combines four distinct hard problems into one product: geo-spatial search over millions of active users, real-time bidirectional event detection (the match), a recommendation engine that must balance exploration against exploitation, and a messaging system with strict privacy guarantees. Each of these sub-problems has its own consistency, latency, and scale profile.
Why the Problem Is Distinctive
A news feed can tolerate eventual consistency for minutes. A dating match cannot. If User A swipes right on User B, and User B has already swiped right on User A, the match must be detected and both users notified within seconds—not minutes. A delayed match notification creates a perception of system failure. Simultaneously, the swipe itself is a fire-and-forget write: the user does not need confirmation that their swipe was persisted, only that the UI advanced. This asymmetry—fire-and-forget writes, latency-critical reads, strongly-consistent match detection—drives the entire architecture.
The geo-spatial dimension adds another layer. Unlike Twitter, where any user can see any tweet, a dating app constrains discovery by physical proximity. The candidate pool for any given user is the intersection of: geographic radius, preference filters (age, gender, distance), algorithmic ranking, and anti-abuse exclusions. Computing this intersection in real time for millions of concurrent users is the core engineering challenge.
Public Operating Baseline
Tinder reports approximately 75 million monthly active users globally, with peak concurrency exceeding 10 million simultaneous users. The platform processes over 2.5 billion swipes per day, generating approximately 26 million matches daily. Bumble reports over 40 million monthly active users across its dating, friendship, and professional modes. Hinge, positioned as the relationship-focused alternative, serves over 23 million users with its Most Compatible algorithm based on the Gale-Shapley stable matching algorithm. Match Group, Tinder's parent company, reported $3.4 billion in revenue in 2023 across its portfolio of 40+ brands.
These are cited public figures. For capacity planning in this design, we will use explicit assumptions stated in the estimation sections.
The Four Architectural Planes
- Discovery Plane: Geo-indexed candidate generation, preference filtering, and personalized ranking. This plane answers: which profiles should this user see next?
- Interaction Plane: Swipe ingestion, match detection, notification fan-out. This plane answers: did two people mutually express interest?
- Communication Plane: Real-time messaging, media sharing, read receipts, typing indicators. This plane answers: how do matched users talk?
- Trust Plane: Photo verification, bot detection, content moderation, reporting, blocking. This plane answers: how do we keep the platform safe?
A strong interview answer keeps these planes separate. The discovery plane can degrade gracefully (show slightly stale candidates). The interaction plane cannot lose a match. The communication plane must guarantee delivery. The trust plane must operate independently of all three.
Key Design Tensions
The fundamental tension is between freshness and throughput. Users expect to see new profiles instantly when they open the app, yet generating a personalized, geo-filtered, ranked candidate list for 10 million concurrent users requires significant computation. The system must pre-compute and cache aggressively while maintaining enough freshness to feel responsive.
The second tension is between privacy and discoverability. Users want to be found by compatible people nearby, but they do not want their exact location exposed, their swiping patterns leaked, or their presence on the platform revealed to unintended audiences. Location fuzzing, differential privacy in recommendations, and strict data isolation are architectural requirements, not afterthoughts.
Key Highlights
- •The system processes 2.5B+ swipes per day across 75M MAU, requiring geo-indexed discovery at sub-200ms latency.
- •Match detection is the critical path: bidirectional interest must be detected and notified within seconds.
- •Four planes—discovery, interaction, communication, trust—have fundamentally different consistency and latency requirements.
- •The swipe is fire-and-forget; the match is strongly consistent; the message is at-least-once ordered.
- •Privacy is an architectural constraint: location fuzzing, swipe-pattern protection, and data isolation are design-time decisions.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will separate the four planes because they have fundamentally different consistency, latency, and privacy requirements."
- "Before choosing databases, let me define which operations are fire-and-forget, which are latency-critical, and which require strong consistency."