A look at how Tinder works. Tinder does ~1.6 billion swipes per day across 70+ countries, and the architectural problem nobody talks about is the match-graph asymmetry: most right-swipes never produce a match, so the write-heavy path (every swipe is recorded) is decoupled from the read-heavy path (matches are rare bidirectional edges). Tinder’s architecture optimizes the two paths independently.
How Tinder Works: The problem at scale
Tinder’s matching problem is asymmetric at every layer. Read path: every user opening the app pulls a deck of ~10-20 candidate profiles, scored on geo-distance, desirability (the “Elo” score Tinder infamously uses), recency, and 100+ features. Write path: every swipe (left or right) is logged. Match path: a match only happens when two users right-swipe each other, which is a tiny fraction of swipes. The system has to serve billions of recommendations per day with sub-second latency, log every swipe durably, and detect matches in near-real-time so the user gets a push notification within seconds.
The core architecture
When you open the app, the Recommendation service queries the Geo Index (Redis, ~5-mile radius from your location), filters against your existing matches / passes / recent exposures, scores candidates by Elo + recency + features, and returns the top 10-20. Each swipe you make goes to Swipe Ingest, which writes to the Match Graph (Neo4j). The Match Detector runs on every right-swipe: did the right-swiped user already right-swipe us? If yes, fire the match event, send push notifications to both, create a chat thread. If no, just record the like for later.
The Elo score, honestly
Tinder’s Elo system (described publicly in 2016 and quietly refined since) is not the chess Elo. It’s a desirability percentile computed from how often your profile gets right-swiped relative to other profiles in your region. The purpose isn’t to rank people by “attractiveness” in some objective sense; it’s to ensure matches cluster within similar desirability bands, which empirically produces higher match-conversion rates. A highly-right-swiped profile shown to a low-right-swipe-rate user wastes the highly-right-swiped profile’s “inventory.” Tinder’s recommendation system explicitly biases toward showing you profiles in your own Elo band, with some randomness to expand the pool.
This is the part of the architecture that’s most ethically fraught and most operationally load-bearing: the recommendation quality is directly the Elo quality, and the Elo quality depends on the volume and accuracy of swipe data.
The match graph is the rare-bidirectional-edge problem
The Match Graph (Neo4j) holds every like and every match as edges between user nodes. The match-detection query is the interesting one: (A)-[:LIKED]->(B) AND (B)-[:LIKED]->(A). Neo4j handles this in single-digit milliseconds for any pair. The write-heavy path (every swipe is a LIKE edge) is amortized because most likes never match: the edges are written but rarely queried. The read-heavy path (when user A right-swipes user B, query if B already likes A) is bounded to a single edge lookup.
The graph is sharded by region because cross-region matches are rare (most users want matches within driving distance). A graph per region keeps shard sizes manageable.
The one non-obvious insight
The “rewind last swipe” feature (paid tier) isn’t a client-side undo. It’s a server-side reverse-edge write that has to handle the case where the swipe already produced a match. If you accidentally right-swiped someone and it matched, rewinding has to dissolve the match on both sides, including retracting the push notification if not yet seen. The architectural complexity of “undo a write that already had side effects” is non-trivial, and Tinder’s published engineering blog is candid that they handle this with a soft-delete + delayed-commit pattern rather than true transactional rollback. The pattern shows up in any system with “undo” semantics: Stripe refunds, Gmail unsend, etc.
Tinder is the canonical matching-asymmetric architecture: read-heavy recommendations (geo + Elo), write-heavy swipe logging (every swipe durable), rare bidirectional-edge match detection. The asymmetry is what shapes every layer of the system.