Scribd
Upload
427 views

Tinder System Design

The document summarizes the architecture of the Tinder app. It discusses 4 main features: storing profiles with images, recommending matches, noting actual matches, and direct messaging. For storing profiles, it recommends using a distributed file system to store images separately from profile data for performance. For matching, it describes services for profiles, matching, and sessions to track connections. For messaging, it recommends using XMPP over peer-to-peer connections managed by the sessions service. Recommendations will query profiles and match users based on location and other attributes stored in a distributed database.

Uploaded by

Raj jain
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
427 views

Tinder System Design

The document summarizes the architecture of the Tinder app. It discusses 4 main features: storing profiles with images, recommending matches, noting actual matches, and direct messaging. For storing profiles, it recommends using a distributed file system to store images separately from profile data for performance. For matching, it describes services for profiles, matching, and sessions to track connections. For messaging, it recommends using XMPP over peer-to-peer connections managed by the sessions service. Recommendations will query profiles and match users based on location and other attributes stored in a distributed database.

Uploaded by

Raj jain
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Tinder Architecture:

Features:
1. Storing Profiles (Images) - 5 Images per user
2. Recommend Matches (No of active users)
3. Note Matches (0.1% of Matching with someone)
4. Direct Messaging

1. Storing Profiles

How will we store images?


in the form of files
in the form of blobs ( blob -> binary large object )

Reasons to not go with blobs:


1. No need of Mutability ( ie changing the image again and again, even if i am changing i will
change the entire image and not bits of it)
2. No need of Transaction properties for the image
3. No need of Indexes
4. Access Control will be required

Reasons to go with Files:


1. Cheaper
2. Faster ( because they are storing images separately)
3. Easily built a CDN (Content Delivery Network - Fast Access)

Use Distributed File System for Feature 1 ie Storing Profile.

Design of Feature 1:
Client -> Update Profile -> Gateway -> Profile Service -> Database
Client -> Update Image -> Gateway -> Image Service -> Database
Keep separate image service because it is a high computational service.

Reference for the File:


Profile ID | image ID | File URL
Design of Feature 4:
For a chatting feature after being matched, we can’t have a client sever protocol due to the fact that,
it would be very inefficient because in this case the client will have to ask the sever again and again,
are there any messages for me? Because the sever does not initiates the communication, it only
responds. Hence, we will use Peer to peer protocol

Peer-to-Peer Protocol – XMPP


The XMPP is going to take a connection and that will be TCP or a Web Socket connection.

Now who will maintaining these connections, for each connection id which user id is connected to it.
So, the gateway service can do it but we can reduce its burden and make a new service which would
be sessions. So this service will contain which user id is containing which connection id.

Reference for the Chatting Database:


Profile ID | Connection ID

Design of Feature 3:
If you match with someone, it could be to send to the profile service or it could be sent to the
matching service, which keeps a table of user Id and user ID.

Now matching service will be checking if you are authenticated to communicate with the other user,
so there will be communication between session service and matching service.

Reference for the Matching:


User ID | User ID
Design of Feature 4:
The biggest problem with recommendation will be to figure out the users who are close a particular
user. We can do that using indexes but when we see that have such a huge count of users active,
you will have to find it for each user, which is basically the core of recommendation.

Now the profile service will have


Name | Age | Gender | Location

1. You can have a distributed Database like Cassandra or AWS Dynamo


2. Or use Relational Database with the use of Sharding or Horizontal Partioning.

Horizontal Partitioning means you take some property of a data; you set ranges in one column
and direct data to a location based on that range.
For eg:
All users having name from A-J will go to database node 36
All users having name from K-P will go to database node 79

Now what if it causes a single point of error, so we can use a master slave architecture.

Recommendation Service:
User IDs | Location

You might also like