Matching app (Tinder)

01 · CONTEXT AND REQUIREMENTS

What a matching app needs to do

A matching app shows a stack of profiles, and the person swipes to like or pass. When two people like each other, the app notifies both. The focus of the exercise is the profile stack and the swipe, not chat or photos.

Functionally, the person creates a profile with preferences and a maximum distance, sees a stack of profiles within those limits, and swipes on each one. On the non-functional side, four demands drive the design: strong consistency on the swipe, scale for many daily users, a stack loaded with low latency, and no repeated profiles.

02 · API AND FIRST VERSION

Three endpoints and two services

The API has one route for the profile (POST /profile), another for the stack (GET /feed, which receives the client's current location), and another for the swipe (POST /swipe/{userId}).

The first version separates the profile service from the swipe service, each with its own database. The reason is that a profile is created and viewed far less often than swipes are written, so the swipe service needs to escalar by itself. For the write volume, the source picks Cassandra, partitioned by the swiping user, accepting eventual consistency as the tradeoff.

1. The app sends the request to the API Gateway.

2. Profile and stack requests go to the profile service, which queries the profile database.

3. Each swipe goes to the swipe service, which writes to the swipe database and looks for the reverse swipe.

4. If the reverse exists, whoever just swiped sees the match right away and whoever liked first gets a push.

03 · SWIPE CONSISTENCY

When two people like each other at the same time

The risk is a race. If the two swipes arrive almost together, each server looks for the reverse swipe and finds nothing; then both swipes are written. Both are saved, but the chance to notify the match is lost.

The source notes that consistency can be relaxed and a periodic reconciliation run that notifies reciprocal pairs. Since the requirement is to notify the last person to swipe right away, the design proceeds with strong consistency, and the comparison below shows the options.

1. The app sends the swipe to the service, which builds a unique key for the user pair, in the same order for both directions.

2. The service tells Redis to write the swipe and read the other person's swipe in one atomic operation.

3. If the other person also liked, the match is created and whoever liked first gets the push.

4. Cassandra remains the durable store of the history, and Redis keeps only the recent swipes.

04 · PROFILE STACK

A fast stack, with filters and distance

Querying the profile database directly is slow, and the location search is the slowest part. The way out is a search index with geospatial support, kept up to date with the transactional database through change data capture (CDC).

Another way out is to precompute the stacks in the background and store them in cache. This delivers the stack instantly, but very active users exhaust the cache and the stack can become stale, that is, contain profiles that no longer meet the filters.

1. When the app opens, the request reaches the feed service.

2. The service delivers the precomputed stack that is in the cache, with no expensive query.

3. A background job recomputes the stacks, generally only for active users.

4. When the stack is running low, the service queries the search index to generate more profiles in real time.

5. Change data capture carries the changes from the profile database to the index.

To limit staleness, the source suggests a strict TTL for the cache and precomputation only for active users; changing filters or location can also trigger a background refresh.

05 · ALREADY-SEEN PROFILES

Never repeat a profile

Showing a profile again after it was already swiped gives the impression that the swipe was lost. The simplest approach queries the user's swipe history and filters out the ones already seen. It can miss swipes and re-show profiles, and becomes more expensive as the history grows.

A first reinforcement is for the app itself to store recent swipes and filter the stack on the client. For large histories, the source proposes a per-user Bloom filter. It can flag a profile as already seen when it was not, but it never fails to flag one that was, so the cost is hiding some profiles forever. The error rate is tunable and tied to the space used.

The operational cost is keeping the filter up to date and rebuilding it if the cache goes down, which is easy to do from the swipes but expensive at scale.