Design Tinder: Geo Matching, Billions of Swipes and Instant Matches

Users create a profile and configure what they are looking for: an age range, how far away a candidate may be, and which genders interest them. Those settings define the candidate pool, so they are first-class data rather than an afterthought on the profile page.

From there the product reduces to three actions. The app serves a stack of nearby profiles that fit the preferences, the user swipes each card right or left, and a mutual right swipe produces a match with a notification to both people. Messaging after a match, photo moderation and paid features are left out because each would add its own subsystem without changing the core design.

Swiping is a rhythm, so the next card must be ready in under 300 ms or the experience feels broken. That requirement is why card stacks are prepared ahead of time instead of being computed per swipe.

Correctness matters for matches in a way it does not for most counters. If two people like each other, the system must create the match every time and never create it twice; a missed match is a lost connection, and a duplicate produces two notifications. Meanwhile the swipe path is overwhelmingly write-heavy, since every left and right swipe is persisted. Finally, someone who already swiped on a profile should not see it again, which needs a cheap way to remember what each person has seen.

Assume about 20 million daily active users, each swiping roughly 100 times a day. That gives around 2 billion swipes daily, which averages to about 23K per second and climbs to roughly 70K per second during evening peaks.

If one swipe record is about 100 bytes (two user IDs, the decision and a timestamp), that is close to 200 GB of fresh data a day and on the order of 73 TB a year. Matches are a tiny fraction of that volume. The estimate tells us where to spend effort: a storage engine tuned for appends, a key layout where checking whether A swiped on B is a single lookup, and no read-modify-write cycle on the hot path.

The data model has four entities: Profile, Preferences, Swipe and Match. Separating preferences from the profile keeps the search filters explicit, and keeping matches apart from swipes lets the small, frequently read match list live in its own table.

Three endpoints are enough. PUT /profile saves the bio, photo references, preferences and the latest location. GET /feed takes the caller's coordinates and returns a batch of candidate profiles. POST /swipes carries the target user's ID and a decision of like or pass, and the response says whether that swipe completed a match. Returning the match result synchronously lets the app show the match animation right away, instead of waiting for a push notification to arrive.

All traffic passes through an API gateway for authentication and routing, then splits into two paths. On the read path, a feed service asks a geo-aware search index such as Elasticsearch for profiles that fit the caller's location and filters. Profiles are owned by an ordinary database and replicated into that index, so search load never touches the system of record. The resulting candidates are cached as a ready-made stack in Redis.

On the write path, a swipe service records each decision in Cassandra, chosen because it is built for high-volume appends. For right swipes it also runs an atomic check in Redis to learn whether the other person has already liked back. When that check finds a mutual like, a notification service sends a push to both phones through Apple's and Google's push gateways.

Building a candidate stack starts with fresh location. Each time the app opens it reports coordinates, and the backend stores them as a geo point on the profile so searches center on where the person is today, not where they signed up.

The search itself combines a distance filter with preferences evaluated in both directions: the candidate must fit my criteria, and I must fit theirs. Adding a recently-active filter avoids wasting cards on dormant accounts. A search index can apply the geo radius and all these filters in a single request.

Next, anyone already swiped on must be removed. Querying billions of swipe rows per request would be far too slow, so each user has a Bloom filter of the IDs they have swiped. A Bloom filter can produce false positives, which means occasionally hiding someone you have not seen, but it never produces false negatives, so a repeat card is impossible. The survivors are ranked, for example by activity and distance, and about 100 of them are cached in Redis. When the stack runs low, a background job refills it.

The naive approach writes my like and then reads whether you liked me. If we both swipe within a few milliseconds, each read can run before the other write is visible, both checks return nothing, and the match silently disappears. That violates the strongest requirement in the design.

A distributed lock on the pair fixes the race but adds lock acquisition and release round trips to every like, which is expensive at around 70K swipes per second. The chosen approach is an atomic check on a single key per pair. Sort the two user IDs so the key is the same no matter who swipes first, for example likes:{min}:{max}. A short Lua script in Redis records the caller's like and reads the other side in one indivisible operation.

Because both swipes target one key on one shard, Redis executes them one after the other, and whoever arrives second is guaranteed to see the first like and create the match. Redis runs with persistence and replication enabled, Cassandra still receives every swipe as the durable record, and the match insert is idempotent on the pair, so a retry can never produce a duplicate.

Swipes are stored in Cassandra with the swiper's user ID as the partition key and the target's ID as the clustering key. Writing a swipe appends to one partition, and the question "did Asha already swipe on Rahul?" is a direct lookup on a known row. The write path never reads first, and log-structured storage turns each insert into a cheap sequential append, which is why the cluster can absorb peaks of tens of thousands of writes per second.

Matches get their own table keyed by user and sorted by time, so listing someone's matches newest first is one query against a small dataset. Every swipe also adds the target to the swiper's Bloom filter, and if that filter is ever lost it can be rebuilt by scanning that user's partition. Old pass decisions can carry a TTL of a few months, which reclaims storage and lets a once-rejected profile resurface later.

Prebuilt card stacks make swiping instant, but a stack may be a few minutes stale, so a candidate who just changed preferences can still appear briefly. The Bloom filter keeps memory tiny and lookups fast, at the cost of occasionally skipping a profile the user never actually saw.

The Redis pair-key check gives correct matches under concurrency, but it only works if Redis is persistent and replicated, so it is treated as critical infrastructure. Syncing profiles into the search index asynchronously lets search scale independently, with profile edits taking a few seconds to become searchable. In short: a geo index finds candidates, swipes are append-only, and every pair of users shares one atomic key.