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

have talked about in this entire series.

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,

broken down and gone deeper into.

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

in a very logical, calm way. So,

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?

And with those features,

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

can fulfill these features.

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.

In that profile,

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.

So I'll just note that down. Five images

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

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

which is how are we going to

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 a good question to ask. So,

number of active users.

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.

That's going to be an assumption.

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

to come up here,

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

0.1%.

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

at most. And more often than not,

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

into.

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.

So storing profiles. In fact,

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

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

Storing images has only one important question in it, right?

And that is how are you gonna store images? So there's gonna be a lot of images.

As you can see, number of active users are large per user.

You have about five images,

which is still a constant factor of the number of active users. And

the,

the question of how are you going to store these images is something which has

been debated for a really long time in the whole technical field that we are in,

computer science. And that is whether you want to store the images as a file

or you want to store the images as a blob. Okay?

So blob is a binary large object,

And those of you don't know about this get back to your database classes because

this is something which is taught in, in engineering. There's also another one,

which is club character, large object. And that's entirely useless.

So ignore that. We are gonna be having the argument of file versus blob.

So images typically are large in size and you

can't store it as a vaca or something.

That's the reason why you have a binary large object,

which is specifically for large objects in databases. Now,

you might think that databases have definitely got a lot more to offer when it

comes to specialized storage compared to files,

but my argument is not really, not really,

because the only few extra guarantees that a database gives you are

mut ability, okay? You can easily mutate the rules in that,

in that database. Basically one data entry.

The second one is transaction guarantees.

So transaction guarantees. The third one is indexes.

Okay? So indexes are mainly to improve your search capabilities,

right? Let's start with mutability.

Are you ever going to be changing the image? You could, yes,

but why would you ever want to do that? Why not just create a separate file?

Because an update or an image is not gonna be just a few bits,

so it's gonna be the entire image, basically. Why not?

Why not store that in a separate file and get rid of mutability,

make it immutable.

So this is an unnecessary feature that the database is giving us.

The second thing is transaction properties. So transaction properties are,

again, not required by the by an image,

because you're not going to be doing an atomic operation on the image.

So you can get rid of this. There's another feature, actually,

I better note that down. So that'll be the fourth feature, which is required,

and that is access control.

So yeah, let's get to the third one again. Indexes.

Indexes are good for searching.

They allow your data to be sorted according to a particular field. Let us say,

you know, you have a profile table in that the name can be indexed.

So anyone who's searching for goov will find that entry quickly because it

binary searches on on the name. So for a, for a binary,

any large object,

that's useless because you're now going to be searching on the content of the

file. That's gonna be ones and zeros, right? So you can get rid of that.

And finally, access control. This is very important.

It's one of the arguments for databases using binary log objects,

but I would say that you can get the same access control mechanisms

using a file system, right?

It is a little tedious maybe, but setting up a file system,

a secure file system is almost as tedious as setting up a, a, a secure database.

So nearly equal. The good things about a file are that it's,

it's cheaper. That makes a big difference.

Storing files the, the other things about

files, which are good, are that they are, they're built for this.

They're built for, you know, storing a file and an image is a little file.

So that's, that's one good thing, but it's a little abstract. Instead,

they're also faster in a way because they're storing

large objects separately.

And you can do that in a database using something called vertical partitioning,

where the profile ID is going to be over here,

and the image ID is gonna be over here,

and then you're going to store the image somewhere else.

But if you're doing that, then why not store it on the file,

which is not just cheaper,

it's also less likely to do a select star nightmare.

So if you do a select star on this table.

.

So instead go for the file system, it's gonna take care of that. I mean,

you won't, you won't do a by mistake, select star on the address and the id,

okay? This is a little bit of a flimsy argument, but it's still, you know,

in practical real life systems, select start is used a lot.

So it's one of the good things. The third thing is that these are static.

So you can easily build a C D N over this content delivery network.

You can read up on this maybe in description below. You can just read up on it.

In general content delivery Network allows

fast access.

One argument for databases which are going to be storing the files. I mean,

at the end of the day, your database is going to be storing all your data.

So it has to have some reference, some address to your file.

And that is going to be the file, u r l.

Alright? And this will be stored in the database.

So we are going to have an image ID

of image U R L and the profile ID

per image stored by user with profile ID in location.

So, and so where are you gonna store this image? This file?

U l it's going to be in a distributed file system, Right?

So your distributed file system is gonna be handling requirement number one,

And that's how you argue for files versus blobs. Now,

if your interview is really,

really pushing you for blobs you could take it, I mean,

it's not gonna really spoil your design,

it's only that it's good to have these arguments with you when you are

logically, you know, talking about what would be better in an interview.

But don't push too hard. If they say that blob is what I want, go for it,

. So taking this first option, let's start designing our system.

The first thing to note here is that we have a client application on

the mobile.

A user actually clicks a button to send us a request, okay?

And over here we have our profile service.