Name: 設計約會交友軟體（System Design: TINDER as a microservice architecture）
Uploaded: 2024-04-15T00:10:14.000Z
Duration: 36 min 41 s
Description: 設計約會交友軟體

So I forgot to say this before we started,

but it's important as prerequisites to know about the system design concepts we

Stop looking at this diagram because you know,

you're not gonna understand until we actually start discussing about it.

And each of these concepts that we are gonna discuss now can be, you know,

So all those concepts will require prior knowledge that that is going to be

given to you through the videos that I made earlier, and also, of course,

through lots of links on the internet. So you, it's your choice.

Just make sure that you have your basics and fundamentals clear before you

actually jump into actually designing a system. Okay, let's start. Hi everyone.

We are finally here. We are finally talking about Tinder,

and we are talking about its architecture.

So let's say you enter the interview room, you meet the interviewer,

and you sit down. So you're asked to design Tinder. Now, in my experience,

I've seen that most candidates get really, really into the game. They,

they start thinking about what services are they going to use,

what kind of databases are they going to use? Take, but, you know,

my suggestion to you would be to take a step back and think of this system

if you have been inventing such a kind of an app what's going to come up in your

mind is, what kind of features will I provide this person?

what can happen is you can actually think about how your system evolves.

Two approaches that you can have for this,

for starting off with this is to start with the ER diagram,

which we are taught often enough in colleges that,

you know think about how the data is gonna be modeled,

and then think about how your services are gonna consume them. Finally,

think about what the clients will be doing to actually call the services.

So that kind of, that kind of thinking is a little too constrained.

It's also too abstract because you're thinking about how to model your data

without thinking about what do your users need.

The second approach is to go from the front to back. That is,

think about what your users need as features.

Think about how your services are going to actually be broken down so that you

And then think about their individual data you know,

requirements per service. So in that way, your system is far more flexible.

It's also a lot easier to start off with the system immediately with,

with feature development. Per feature development.

So the features that we are picking up in Tinder are storing profiles.

Alright? So you won't just write this down. First of all,

what you could say or what you could ask your interviewer is,

so you are definitely gonna be storing profiles, right?

So that's an obvious question, but best to get it outta the way.

there are going to be images that's really important for any dating site.

So one thing to remember here is that images will

be stored in the profile. A follow-up question can be,

so how many images per user do you want? That could be five.

per user. Is there something else we wanna think about?

Images? No, we can move to the next feature that might come up,

recommend matches Yeah, to look into that. But if you think of this in a,

in a storyline, what happens is you go to any dating site you make a profile,

and that's how you think about storing profiles.

You start accepting or rejecting people based on your

preferences. So that would be recommendation system.

That would be some sort of recommending matches. Yeah. in that case,

what are the questions you can think of? How many active users do you have? Is,

Is there something else you wanna ask? Maybe are there,

are there certain countries where there's too much population stuff?

But don't get into too much details. Again, if you're,

if you're running behind too many questions per feature that also shows that

you're getting into too much detail per feature. So keep it fluffy,

keep keep it flying in the air. Even now then you have the third feature,

which is the best one, which is when you match with someone.

So if you match with someone, you need to note that down. And you need to,

you need to do something between the two people.

So one of the things you wanna do is you wanna note down matches in which case

the number of active users is kind of enough.

You can take a percentage of that as the number of matches you'll have per day.

I'm gonna assume that typical Indian match rates are going

which is for every swipe you have a 0.1 percentage of matching with someone,

right? So the number of matches you'll have per person is going to be

So that's gonna be number of active users into 10 days to power minus three

matches. And the fourth one is, once you have matched with someone,

of course you need to chat with that person. So there's direct messaging,

which will be a feature of Tinder once you,

once you guys match, right? In direct messaging,

what kind of questions should you ask? Well, we'll get to that,

we'll get to that. For now, we have four features.

Avoid taking too many features because it's going to be an hour long interview

you are going to be getting into the details that the interview wants you to get

Any ways you don't need to pull out more and more features just for the sake of

showing that you know, you can implement these. Okay?

So start with four or five features. Let's start with so profiles.

the previous video also talked about this designing Instagram. There,

there was a lot of jargon that a lot of you felt was there.

字幕列表影片播放

設計約會交友軟體（System Design: TINDER as a microservice architecture）

sort

relevant

figure

content