System Design ( Day - 19 )

Tinder Architecture

Let’s analyse how the tinder works through its architecture.

Features

1 . Profiles → We can store upto 5 images/User
2 . Recommended Matches
3 . Storing the Matched peoples
4 . Direct Messaging with matched person

Profiles

How we can store the images, in a Database as a BLOB( Binary Large Objects) or in a File system,
we can’t store images on the database because it’s expensive, Files systems are literally build to store fils, and an image is a file. file systems are way more faster that that the databases because its storing the large objects separately, The file URL is stored in the database so that the client can access that. Distributed file system is going to be handling the files but that files can be accessed through url and it will be stored in the Database.

Design

Clients are connected to the gateway service, through some authentication login or token or OAuth or something else, if He/She is a authenticated user then the request is directed to the Profile service and get the data for the user or update something in the profile service, here what we have done is decoupled the services by decoupling the gateway service and getting the details and checking if the user is authenticated or not, and then allowing the user to access his/her profile, to get the data or update something.

we are going to have a image service separately for storing the images in the distribute files system and that image url’s are going to store in the database with userId, profileId, imageUrl’s and so on.

For the direct messaging (Chat), how do i connect client A to client X, like imagine Client A matched with client X and they wants to talk, then the user is going to gateway and telling the hey send message from user A to user X, we have to use peer to peer protocol, which is XMPP ( Extensible messaging and presence protocol), we can’t communicate with the client-server protocol which is a HTTP, the both users will get the messages through the XMPP protocol, the xmpp is going to get the websocket connection, now who’s going to maintaining these connections, we need to know how’s using which connectionId, we can create another service for handling the sessions to store the connectionId’s and who’s going to use those. and the messages are going through the websocket to the clients who’s sending and who’s receiving it. that is taken care by these session service.

When it comes to storing the matched peoples, we can store the data like who you are matched with or who you are asked to matched with these data can be stored in the local storage in the client’s mobile, the problem is when the user clearing the app’s data or uninstalling the application the data is lost, what we can do is we can have a matched service and it’s going to store the who matched with who like A matched with X these things are storing in the matched service database, so that if the user is going to uninstall or clearing the data, when that user is logging in again then tat data has to be retrieved from that service. these matched service is going to talk with the session service internally, to identify if these peoples are matched or not.

final thing is the recommendation system for the users to match, for the recommendation we need the users age, gender, location to analyse the user and give the recommendation, for these systems we could have a NoSql Db like CasandraDB / DynamoDB, so that its so optimised for these kind of things, if we don’t want to move to a NoSql database then we can use Sharding like horizontal partitioning in the Sql database with the criteria as location, age and gender we can differentiate them easily with sharding, with the location we’ll get a chunk of data inside that particular location this data is pretty less compared to everything in this we can do search operation with the constraint of gender and age, we’ll get the data very easily and efficiently. we can do these search and sharding as per our requirements, what if any of the node fails or single point of failure, in that case we can have the master-slave architecture, to reduce the single point of failure.

the recommendation engine is simple like its a recommendation service which is maintaining all the above things and for the update like for an hour that database is going to update the location so that if any of the profile updates then it has to be update in the database and its sharding nodes also, for maintaining consistency.

These covers the 4 features that has to be implemented in the tinder application, ya we can dig deeper into each topics that we have discussed, Feel free to connect if you have some suggestions or feedback at Manoj Kumar or www.linkedin.com/in/manoj82202