Tinder Microservices Architecture | Online Dating App System Design
HTML-код
- Опубликовано: 30 июл 2024
- This video deals with the system design of Tinder Online Dating app. Please like the video and please do comment if you find this video useful. I will really appreciate it as it helps the channel. In this video we are discussing following for the Tinder System Design:
00:00 - Introduction to Tinder System Design
01:05 - Functional Requirements for Tinder Service
05:05 - Non-Functional Requirements for Tinder Service
07:40 - API Specs for the Tinder Service
11:00 - High-level Microservices Architecture of Tinder Service
12:40 - System Design of Routing Service in Tinder Service
13:20 - System Design of Profile Service in Tinder Service
14:40 - Detailed discussion on where to store user images
26:35 - System Design of Swipe Service
29:40 - System Design of Recommendation Service
44:40 - Final Remarks
We discussed three options for storing user images in the Tinder System Design:
1. Images stored in the datastore
2. Images stored in the file system
3. Images stored in remote object storage service
In Recommendation Service design, we discussed:
1. Types of search preferences
2. Geosharding techniques to use - one discussed in Uber or Quadtree approach
3. Search agents and how they would perform search
4. Categories of machine learning algorithms used for recommendation systems
Some questions for you guys:
1. What consistency model should Tinder Service use?
2. Should we store both right and left swipes or just right swipes and why?
3. How recommendation service avoid sending duplicate profiles to the user?
Distributed System Design Interviews Bible | Best online resource for System Design Interview Preparation is now online. Please visit: www.thinksoftwarelearning.com?RUclips-tinder
Please follow me on / think.software.community if you like to get notified about new course chapters getting added or when we will start another round of mock interviews and you want to participate in mock interviews or any other updates. I will also take your suggestions there about the course and the channel.
Check out our following articles:
- How to Ace Object-Oriented Design Interviews: / how-to-ace-object-orie...
- Elevator System Design - A tricky technical interview question: / elevator-system-design...
- System Design of URL Shortening Service like TinyURL: / tinyurl-design-from-th...
- File Sharing Service Like Dropbox Or Google Drive - How To Tackle System Design Interview: / how-to-tackle-system-d...
- Design Twitter - Microservices Architecture of Twitter Service: / design-twitter-microse...
- How to Effectively Use Mock Interviews to Prepare for FAANG Software Engineering Interviews: / how-to-effectively-use...
#FAANG #Facebook #Google #Amazon #Apple #Microsoft #Uber #Netflix #Oracle #Lyft #SystemDesign #Interview #ComputerProgramming
Hello everyone. Please let me know if you find this video useful in the comments. And please do like the video if you find it useful. I will really appreciate. Thanks :)
Great video, don't stop this deep detailing
Thanks for the comment 🙂
Thanks!
I really liked the in depth explanation. Thanks for making these videos!
Thanks for the comment 🙂
Great video, thanks for making it! I look forward to watching the rest of your videos. One request: I think people like me who are less familiar with system design would benefit more if you gave the answers to your in-video questions rather than just leaving them unanswered.
Thanks for the comment 🙂. Usually I am giving the answers in the course :)
Hi, Great video! Very informative
Thanks for the comment 🙂
Great work sir!
Thanks for the comment 😊
I found it very useful and insightful, happy to explore whatsapp videos for any missing stuff. I am not a developer but this gives a good overview.
@Think Software - Could we improve the performance of the match profile service if by storing the ( user1, user2) tuple in a NoSQL database, as reads are much faster in them? ( Mongo/Redis)
yes
Very Informative video.
Thanks for the comment 🙂
This guy chill af
thanks for the comment
very helpful
Thanks for the comment.
Very good explanation covering most of the edge cases which are normally not included by most of the other system design tutorial. One suggestion, please include back of the envelope calculation and data estimation too.
A request can you please make next system design tutorial on online delivery platform or courier services like delhivery or dunzo (how would you suggest the load balancing of delivery partner based on load).
Thanks for the feedback. I have noted your suggestions to my backlog.
One question plz. for APIs part, should we write methods like createAccount(), or do we need to write down POST /v1/user/create/.... ?
It depends on the interviewer. E.g. the api itself is createAccount(). POST /v1/user/create is a HTTP implementation of it.
Thank you for the video!
BTW, I don't think it's a good way to pass the JWT, but the userId which is usually inside the JWT. Because sometimes the JWT might be a refresh token which is changed every couple of minutes.
Great videos!
Thanks for the comment. It depends on how you are creating the JWT token. Usually in the case used in this video, the payload contains the user id. So once you validate the JWT token and authenticate the user you can get the user id directly from the JWT token.
After thinking for quite sometime, I think the best way to store already matched profiles is a bloom filter. This is only way we can store this info without linearly exploding our datastore. Please let me know if I am correct
Though sacrificing some accuracy, which is tunable.
Correct
1. Consistency model - Most of the services can use eventual consistency model. High availability is must.
2. Left swipes - Depends on if we want to use that information for analytics. For e.g a person with many left swipes can be given recommendations to improve the profile details like photos, interests etc. Otherwise since anyways we only use right swipes for matching, and not showing already visited profiles, we can skip saving left swipes.
3. Not sending duplicate profiles - Include a hard filter in the recommender service and one more table about profile visitors and last visited timestamp. When API calls get recommendations, this filter should filter from the MFU cache the profiles whose visitors include user with user id who called this API.
1. and 2. are correct and for 2. you need left swipes to improve recommendations.
However, can you explain more what do you mean by "hard filter"? how it is defined? and one more table about profile visitors? Also if the filter is only filtering MRU cache profiles and lets suppose you are caching 1000 profiles but what about those profiles that were sent before that? So there is one other approach to solve this.
subscribed
thanks
Given that user can either like/dislike the profile & since we have the req of not showing the same profile repeatedly, we need to have this info saved for disliking the profile. We can keep collecting this info though & make a batch API call for the same less often than like profile API call. @Think Software What do you suggest?
Thanks for the comment. This approach will not work due to the large number of scans that we would be doing for every user and the way we have designed swipe service database. I will give others a chance to come up with a right approach before telling myself.
Which database would you recommend is used for this type of system?
Which Microservice are you asking about?
RUclips recommends this video to me on Feb14th
😂.
Great infrormative video. learned a lot. can you also write something about object storage. Also how will the overall design for not showing the same results again n again for a user works?
Thanks for the comment. I will be covering the design of object storage soon. As far as the second question is concerned about not showing the same results to the user, this has been addressed in the course.
For consistency, registration point of view we need strong consistency. For other users point of view is it okay to update some milli seconds after. So there we can use eventual consistency.
Thanks for the comment.
Few comments on the API’s topic at min -8:00. Why are the names of the API’s verbs. Isn’t the action like put or post indicate what an api should be doing ?
Why is JWT being sent as a parameter instead of authorisation header ?
Http/Rest is one implementation of the API. What if the api need to be implemented using a custom RPC protocol?
@@ThinkSoftware you have a point. Isn’t it a good idea to pass action-get,delete,update as a parameter to RFC than using action based API’s.
I am trying to understand the best practices here
Great video as always! One question - why are you sharding user table by user id? If you shard it by location or zipcode the search would be faster. SInce the search is location based it will have to look in lesser shards
Thanks for the comment. Check ruclips.net/video/XFQIW2R_Klk/видео.html we are geo-sharding the table. I think you just skip over the video quickly and saw user Id as primary key :) You should watch it full. It is helpful for the channel as well ;)
Thanks. Yes you are right. I missed that part . Keep the great work going !
It is my first time here. Came here after watching your comment in GKCS, maybe.
This video is very much insightful!
Thanks for sharing your knowledge.
Now I am going to watch the dependencies of this video!😅
Glad it was helpful! :)
Why is the playlist not ordered..? You are giving reference to the Uber video which is later in the series 😔
I am playing with the order of videos in this playlist :)
@@ThinkSoftware Playlist is not in order. please ads the sequence in the description box.
If we won’t store dislikes, how we will filter out profiles that shouldn’t be shown again for certain user? So seems we have to store this data, at least for some time
Thanks for the comment. This is discussed in the course
@@ThinkSoftware can you share link to course and how to get in touch with you?
@Mark-fs9ke you can find the course link in the description of the video
If I don't store disliked profiles, how can I avoid retrieving disliked profiles in the app? I have to store it some way 🤔
Thanks for the comment. It all depends on the requirements.
Great video but I would mention how you would generate a userId.
Thanks. I have actually discussed this in some of my previous videos so didn't discuss here.
@@ThinkSoftware I see, which ones? Well done again and thank you for taking the time to make these.
I won't tell you so you have to watch all of them 😁
Answers: 1. Eventual consistency is good in most of the micro services.
2. Why 3 API servers: If one of the serves is down for maintenance then we dont want single point of failure keeping 2 servers. Also for high Availability we can scale these servers hor.
3. To avoid duplicate profiles: We can keep a table of already-matched profiles for uid in a B-tree. Next time user searches, we can delete if same record is present in Btree. This should work Ok for fairly decent number of searches in Btree. The downside is with increase in number of inserts in Btree.
Thanks for the answering :)
I am not quite sure how we can use BTrees efficiently here. Can you please elaborate. From what I know BTrees are used for maintaining indexes of indexes, to primarily reach a point in file system in logN time. Please correct me if I am wrong.
In the course I have mentioned what would be best for this. Certainly not BTrees.
Hi
How can I contact with you ?
You can contact me via the email mentioned in the channel or the course website.
@@ThinkSoftware I sent you an email at info@thinksoftwarelearning.com
Thanks
Good one, but I am not going to like instead dislike as we have already liked the other video where you have discussed. In 10 mins you have shown 5 different inks to refer to understand this video better? Seriously? The content is good but not upto mark.
Sir, after interviewing, I realized that the details you provide are good enough only for SDE 2 level, I got rejected from Flipkart SDE 3 (which is basically Amazon High SDE 2) following your approach and level of details.
I know several people who got Amazon L6, Google/Facebook L5 after going through my course. Are you sure that it was your system design skills and not anything else that got you failed the interview? And you have prepared the way I have discussed in my recent video.