System Design- Tinder | Cost to develop | How to earn revenue

This content originally appeared on DEV Community and was authored by mukulalpha

In this article, we’ll look at the design / system architecture of dating apps like Tinder / Bumble / Happen/ OkCupid / Hinge. How much does it cost to develop a dating app like Tinder . To get started, let’s understand the app and the features that we will talk about in this article.

This article mainly focuses on the architecture of Tinder.

Tinder’s technology may look simple but when a user left or Right swipe in the app, and a match is found. But Behind the scenes, however, a giant infrastructure consisting of thousands of services and terabytes of data supports each and every swipe and match on the platform.

What is Tinder?
As the modern generation of young people embrace the dating lifestyle, the online dating segment continues to grow. It requires a special technological spark to cultivate the feeling of using such dating apps and achieve long-term use. With the transformation of dating apps, Tinder is a good example of how dating apps can be transformed into a highly profitable business. The Tinder dating app is different from all other types of dating apps because it has a high matching conversion rate. Because of its user-friendly features, it is a hot topic among the younger generation. You can select your communication partner by swiping. When this sliding is mutual, communication opens a two-way channel. Hence, developing a dating app like Tinder is the same thing as developing a relationship, and it takes time and investment to make it unique.

The uniqueness of the tinder applies to the geographical proximity as the key aspect and makes it for individuals smoother to produce with other individuals of their preferences. You can simply view the possible matches and left(NO) or right (yes), initiates the process. The app analyzes user data with geographic locations, mutual friends or similar interests. The users must call their age and gender to the individual, with which they use a tinder to inform the other users with the same interests in their environment.

In Short Tinder is a social dating mobile app designed by UX / UI designers that allows individuals to search and find the right person to connect with the right person through assistance. Support for chat options is consolidated within the app. Sign In to Tinder app requires Facebook login so location and interests are used to find the right person. Users can make their profile look exciting by adding extra details and descriptions to their profile.

SCALE at which TINDER operates:
57+ million members
12+ million active users
55+ Billion matches
100+ Million downloads
1.8 billion swipes every day (left swipe, right swipe, super like)
40+ Language support

Design needs to be scalable to support 57+ million userbases. Tinder supports more than 40+ languages, which means that users are spread all over the world. Hence, this cannot be a simple application hosted on a single continent, but needs to be well distributed to provide the best performance to all users worldwide.

Tinder is entirely hosted in the AWS Cloud. There are no web applications other than IOS and Android. Tinder uses AWS amplify to develop and test mobile applications, MongoDB for DB and Redis for caching and in-memory databases.

Features:

Login using OAuth (Facebook)- The method of logging in via Facebook or phone number is very simple. The dating app algorithm extracts basic user information from Facebook, skipping the same old methods of filling out forms and creating personal profiles.

Swipes (Left, Right)- Swipe may be a distinctive sense resolution. This feature is designed to improve the method of finding dates. Swiping to the right means you like it, and swiping to the left means you don’t like it. The swipe option interface makes online dating clearer and more exciting.

Matching- The users would be obligated to acknowledge if they need some match for the appliance. This shall support them to approach different users whom they like. Also, pairs facilitate in monitoring that the two users have joined to each other with their agreement. Also, the feature includes un-matching that the user isn’t any longer fascinated by communicating. This supports system in avoiding negative spamming, stalking, etc.

chat- In order to talk to each other, candidates need to establish a means of communication with one another. Basics would be to possess a 1 to 1 chat messenger where they will send text messages, audio call or video call through the application.

push notification- The users are notified on a real-time basis just in case the person is found nearby their set criteria.

super likes- The user can swipe up or send a heart or a rose(different application provide different methods of super like) to other profile to prioritize them in the selection queue.

Recommendation Engine

An engine which provides several hundreds/thousands of profile when a person logs into the Tinder .

let’s talk about the features of the recommendation algorithm that tinder is using.

Tag Collecting: When a person performs OAuth using FB, Tinder collects a lot of important information like location, age, distance, gender preferences, places they’ve visited, likes, dislikes, etc. It also extracts a lot of information from photos and what we write in our profile to better match.

Cluster User Base: when a person enters / logs in to Tinder, they get a random point from Tinder and based on that point they fall into some basket, let’s say we have a basket from 1 to 10, this grouping helps to select these people. people in basket 1 prefer more / match people from buckets 1, 2 and 3. This is mainly due to the high probability of matching based on your likes and people who have similar tastes.

Active Use: Tinder’s main goal is to connect people, establish meaningful relationships, so if one of the parties is inactive, it doesn’t add up to Tinder’s main goal. Therefore, it is important to know how actively the person is using the app.

Your pickiness/Bad actors: If one is doing too much of right swipe, it’s bad, you may not be shown recommendation of other people. Also if one is not doing left swipe at all, still one is not gonna shown in the recommendation of others, as they are not contributing towards the objective of this dating application.

Do you reply? : How willingly a person is replying after a match. If the user don’t engage in longer conversation or messages are not exchanged than those profiles are penalized and not shown in recommendation of other people.

Progressive taxation: If one is getting too much of matches/attention, to make it fair for others, Tinder normalizes this by not showing that profile to many other users. At the same time, if someone is not getting much attention, tinder starts bringing that profile to other users.

Recommendation Engine properties:
This recommendation engine brings up the profile of other people based on the above-mentioned points.

Low latency: When a person logs in to the application, we need to load profiles/potential matches profiles real quickly. Therefore, our Recommendation Engine needs to have low latency(able to load profile faster).

Not real-time: It’s okay if it’s not real-time ie if someone newly joins tinder it’s okay if it takes some time to show this person’s profile on other accounts.

Easy to shard/distributed: Since we have tons of profiles from across the globe, this recommendation engine should be able to shard the data as we can’t keep it in one system.

Full-text search: we need to search through the whole profile of an individual considering different parameters ( location, age, distance, gender preferences)to provide better recommendations.

HTTP interface: or web socket to get the data and send it to the application.

Structure data: XML/JSON

What Tinder uses for storing and searching through data is “Elastic search” which is basically a search system.

Initially tinder was started with one cluster and couple of shards but after gaining popularity they did distributed system.
Elasticsearch is able to achieve fast search responses because, instead of searching the text directly, it searches an index instead. Additionally, it supports full-text search which is completely based on documents instead of tables or schemas.

Data are clustered for a given location. The whole point of dating apps is to meet people in real. If I am a user from location X, India, I will obviously like to get a match with someone who is from location X + (10 -50km) depends of users preference. So, how to achieve this?

How to shard data to make elastic search queries faster?

Shard the data by geographical location.!!

We here are dividing the whole world map into small boxes. We can place each server in these boxes to serve any requests originating from these boxes (ie particular lat-log within that box) will get served by servers in that location ( Ideally these servers can be at any physical location, but for each of these boxes/cells, there is one designated server). Now there are certain boxes where the population is high, there one server won’t be able to serve all the requests.

So how can we divide the world into boxes and distribute the load across our servers?

The size of the boxes in different areas is determined by Unique user count, active user count and query count from these regions. These points decides the size of the box/cell.

We have to find a balance score on the basis of the above factors to get the optimal size of the box/cell (for which we use Google s2 library to save these cells) and see the latency/performance for that area.

Whenever a person wants to open tinder, his phone makes a query to a system .This system is basically a mapper system which based on the lat-log of the user gives information to the application/user that all of your data is stored on which server. This server is the server where users information lies as well as this can be the server where user’s potential matches lies. As mentioned before servers can be in any physical location, but all the data belongs to that particular cell will reside on that one server.

Now consider this above map, let’s concentrate on cells 1,2,3,4 and 5. Information belongs to there cells will be store on ser1,ser2,ser3,ser4 and ser5.

So if a Tinder user is residing at cell 3 and has set range as 50 km i.e user want to know all potential matches within 50 km range from user’s location. The radius of 50 km includes all these cells from cell 1 to cell 5. Mapper will know to query data from all the cells which rely in 50 km range and gather recommendation

That’s how recommendation works on Geosharding.

1) Recommendation Engine:

As soon as the new user sign-in to the tinder app using FB OAuth, his profile details go to the ES feeder service using HTTP/ WebSocket. A copy will be store in DB also (by user creation service which adds it to the persistence) and another copy to the elastic search as we need a fast search for the recommendation. Kafka consumes these messages as need to index these data asynchronously.

ES workers pick up the message and send it to the location to the cell mapper which uses the s2 library and has lat-long information. It returns the shard to which this information was written. The ES Worker then notifies the ES, and uses the ES API to write the information to that particular shard.

User information is now saved in Elastic search and he is now ready to do left/right swipe. Then it calls the recommendation engine and which in turn call to the location to cell mapper again with lat log and it returns multiple shards to which it makes parallel calls to Shards and gets couples of documents/profile and send them via HTTP / web sockets .Now all the profiles are being rendered to the user and he’s ready for left/right swipe.

2) MATCHMAKING:
Let’s consider that there are two profiles X and Y

There can be three situations possible:

1. X and Y right-swipe each other at the same time.
2. X does right swipe to Y and Y doesn’t.
3. Y does right swipe X and X doesn’t until now.

There are millions of matches that occur every day. We can have one matching service one cell or We can group couple of cells together with one matchmaking service. so there will be couple of matchmaking service up and running (there will be lots of queries for recommendation queries so to balance out queries per location) and each matchmaking service belongs to couple of cells instead of just one cell as was in case of geosharding. Match also works in the same manner. Match won’t happen between countries, It will happen in the cell where a profile is recommended to a user.

For eg if we recommend 100 profiles to user, chances are there will be on an average 20/30 swipes, so we don’t need one matchmaking service per cell.

Whenever a user do the right swipe, a message is send to the matchmaking service preferably by web socket, where the location manager determines to which shard or matchmaking service this message will go, and redirects message to the gateway, which connects to Kafka. The message is now in the queue. Depending on the number of shards we have got as a result form location manager service, there will be one or many matchmaking services to which this information will be broadcasted to. Information captured here is who is right swiping whom, location, and other metadata. There can be parallel workers which keep reading message coming from the Kafka queue.

If X happens to right swipe Y , then an entry like “X_Y” enters into Redis and leaves it as it is. Now when Y right swipe X , then again the same process happens, match worker picks the message and checks in Redis weather “X has ever right-swiped Y’ i.e we will definitely find key “X_Y” and check for the metadata, which means a match has happened and message will enter in the matched queue which gets picked by match notification and through web socket sends it to both X and Y saying “It’s a match”.

If for some reason, X has never right swiped Y then what will happen? Then just a record “Y_X” will enter into Redis and that’s it. when X right swipe back Y then before adding the key it will check for the key.

3) Passport Feature:
When a user moves from one Region/location to another (could be travelling or moving to different places). This could be happening with in the city, state or country. When user open the app from new location a request is send to the server and with the help of the location mapper Data of the user from previous location cell’s shard if transferred to new Location cell’s shard.

User login + profile for tinder
We already know the ES stores user info, that is already geosharded .why don’t we just have one more API expose from ES to provide specific user profile info. The only optimization we can do is to have one more layer of cache in form of ES so that we can have better performance. We can store user-related info in a database as well. We can have RDBMS as we won’t have too many of records also it needs to be geosharded. so if geosharding is taken care of, we can have our details in RDBMS. We can also link order table info with the user table. We can also opt for NoSQL as it’s auto sharding, it automatically scales itself. We can go with MongoDB as well as it provides ACID property and sharding by geo.

How to enable user login? A user can log in using FB OAuth by registering our application in FB API. We can get lots of information like places user has ever visited, likes, dislikes, close friends ,etc. As Tinder wants to build relationship app, we need to have legitimate profile and decide should we really need to show this profile to other or not. We don’t need to implement sessions in here. Since we are trying to write an app in native android or apple SDK, we don’t need to have sessions all we need to maintain is authentication token.

MONITORING:
Without monitoring, we don’t know what’s happening with our system and also to check system performance and SLA compliance. One such tool is Prometheus which provides features like altering, write queries, and also stores time series data.

It can be used to monitor the application ,collect logs and monitor system’s performance. All the user events get forwarded to Kafka which then gets read by Prometheus where we write aggregators to identify latency in any geoshard(for eg: Suddenly our app will get trending by one tweet and lots of users start login in, traffic increase in that geo shard — ASG). All these information gets captured in dashboard.

Kafka is like an event sink where we can push any kind of data which internally has lots of topics and we can read it at Prometheus. The same system can leverage to consume other logs which generated by other application and these files get read by filebeat or logstash and get forwards to Kafka and can use the same system to track system performance.

Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing.

Content moderation:
Constantly keeping eye on content. For eg : one can use celeb pictures or write bad status what if everyone is doing this and tinder is not suppressing this, then engagement goes down. Therefore, moderating content is important.
How to achieve this?

Every action performed by an user is an event, like user updates the picture, updates the status or does a left/right swipe, these event needs to get pushed in event sink and get stored in persistence. There we need to use some technology like map-reduce or Kafka streams or spark to get the useful info from event run Machine Learning algorithm on recent changes to check if the profile pic is user’s profile pic or is copied/using celeb pic, No swipe, only right swipe. We need to detect all these event, we also need to keep an eye on the rate at which the user is doing the right swipe, whether he’s really reading it, or blindly doing the right swipe.

How to make an app like Tinder?
When researching how to make a dating app like Tinder, you need to understand its exciting features. In addition to the simple registration and geolocation functions, there are also some exciting features, such as rewind options, super likes, unlimited rights swipes, and change location according to subscription plans. There are some other additional features, such as in-app purchases, social media integration, prevention of abuse and uncensored content, anonymous users, and matching suggestions using advanced matching formulas.

How much money do dating apps make?
If you are thinking — “how to make money on a dating app?”, then you have to look at the options below:

In-app purchases: In-app purchase is a regular way of earning profits employed by different types of apps by offering additional features. The same trend has been employed by tinder to offer additional features like icons, emoji, etc. This trend has been successful across mobile apps of different niches. Features can only be unlocked when users pay the fixed amount and subscribe to the plan.

Subscriptions: This is an option to give a scheduled trial period for users and charge a fixed subscription fee after the completion of the trial period for using the services. This is a highly used method for earning through the apps.

Tinder Plus: It is helpful for users who want to subscribe to the freemium model that offers extra options. Tinder app allows the users to start free for certain periods and then charges for using its extra features like a change of location, unlimited swipes, etc. The subscription plans are divided into two parts namely Tinder Plus and Tinder basic.

Tinder plus consists of all the exciting features that will make the users excited once they know the usefulness of the app. If you are looking to build a similar dating app like tinder, then it is wiser to follow the same trend and make all the exciting features chargeable after a scheduled trial period. Tinder has also differentiated the costs depending on the age of the user.

Tinder gold: This plan is exclusively for new members of the app and varies according to the age group of the users.

Sponsored content: Many business enthusiasts have partnered with Tinder to present their sponsored content to the users.

Profile Lift: Tinder asks for a fixed amount from the users to boost the profiles to the top that will enhance the profile views along with some additional features.

Ads: Ads are given to third party agencies for marketing on the apps. This will be useful for other business owners to show their products or services while giving you good profits.

How much does it cost to make a dating app?
The cost of developing a dating app significantly depends upon important factors like app size, app platform (Native or Cross-platform), design elements. level of functionality enclosed in it. Incorporating the fundamental above features may decrease your investment value. however, incorporating further functionalities could need additional funds and development costs

In this article we’ve discussed the design architecture of Tinder with Recommendation Engine , Geosharding , Matchmaking Engine User profile + login and content moderation. Factors to keep in mind while developing a dating app and ways to earn revenue…

Stay connected for more content like this

This content originally appeared on DEV Community and was authored by mukulalpha