Hi everyone welcome to another mock interview with exponent.
Today i am here with yen lee,yen lee want to introduce yourself?
yeah,hi everyone,i am yen,i am currently work as a senior software engineer at Tiktok, on the mobile team,and previously i was at mate for four years work on .and also ARBR for the Facebook released.
yeah, i am happy to be here doing mock interview.
, am happy to have you.
so,my qustion today for you yen is i'd like you to design either Tender or Bumble? take your pick.
before i jump straight into the design.let me go over the functionalities and requirements.
so i would list out kind of like the functionalites we're gonna be touch on today.
so for example,when i am think of app like Tender,i am think about like profile that probably be creating when the user and probably like feed,slash recommendatuon and like matching,so like swipe right,and if two users like swipe right on each other would be that two users on the backend.
and then, private messaging,so two users they are , probably be creating a thread for texting an exchanging messages, uploading images and videos in private inbox.so images,vidoes.
and then just kind of going a little bit more detail on the profile creation, probably like bio,preferences and then images for and videos maybe.that is ?
so kind of the core functionalites that i am of,let me know if i missing anything?
i think this is a good start.
and then add a little extra if we have time so something like super like that i so i personally not been $\color{red}{active} user of Tender,but i kind of konw what super likes.
and then system monitoring,or like logging,just kind of of the system.
and then like subscription model which actually platform. i curious why system monitoring logging is under extra like what that decision put it on there. so it is more sake of the interview just because i think logging system and monitoring is pretty much like sort of design for the sake of interview i think is core component but i don't want dive super deep this part of ,if we have time.
okay,sounds good.
so next i think we can discuss a little bit about the traffic.
roughly i am thinking from like social media app perspective,i am thinking maybe they have 50 million users,i am just here a million users active per day.
so not everyone tinder but there can be 50 users by .
and then let is say 50k new profile I be this numbers.
and then like 1 billion matches per day,the number is kind of roughly estimated could be a little on the ,but essentially this have little rough on like the what we for all the images for the profile, so let'say. there is 50 million users and 1 million active users let's say like 500k new profile created everyday.then i think we can probably do some on the photos storage in terms of profile photos storage let's say 200kb per photo average 6 photos per user and then there's 50 million users roughly plus like 500k new profile created.if we roughly would be looking at like 300 to 600 TB, i think.
and then for messaging there's probably will more here,so i think for messaging,we can say there is 200 million messages exchanged,and 10 million photos uploaded everyday,and we can do more deep dive into like this storage part i get into that the desgin.
yeah, i think this is kind of the background of functionalites and requirements that gonna base my design.
do you have any other qustion before I into the design portion.
no,i think we can dive in
so let's with,let's just go down from like the functionlity here let's go from profile creation.here i am think of creating profile and then,let's say we need to upload the images and also creating, all the preferences and like the bio infomation,so the client perspective start from the client side,i think that the flow that i think of is when user are kind of setting their profile.
they'll be kind of answer a series of questions,and so those are kind of like a text form with like I'm thinking like a JSON formart,but they'll also be uploading images
so what I'm thinking is they'll probably frist need to upload iamges before they can successfully store everything together.so the general flow that I am thinking of is they'll probably need to upload and their profile images to upload services,touches like applictaion services,so this will be sort of like transcoding the images or resizing the images to make sure that we don't store size and we can save a little bit space and doing some other kind of processing on the image to ensure like what we want to find filter or do some encoding or something.
and we can store into the back end blob storage.this is like kind of image pipline and i want to assume that it kind of return some sort of image ID for each of the iamges which we can use for the overall profile JSON matedata,i think here before i dive into the design of the whole profile image, I'm just gonna outline what like profile data kind of looks like.
so for profile data I'am thinking there's gonna be profile ID which is string,and then user id also is string,and just kind of noting that i have profile ID and user ID,becuse if the user decide delete profile,once thet do find like a partner and then if unfortunately they need to break up with them and recreate new profile they'll be a different profile ID for the same user.
and then for preference,there is another JSON so like for gender,string,and if they have like low,like age around perference,and then other kind of file prefernce they have,i won't them.
and some sort of bio infomation themselves,so gender,age,and the location infomation and other types of bio infomation.
and then photo IDs which will be,just list of IDs,so the list of IDs are coming from the back end service once the uploads successful,so only when they are able to upload their profile actully finish this profile data.
and then do that,we can go ahead kind of the second part of the pipline which is the creating that profile into that to the profile database,which I'm thinking of using sort of like nosql database to kind of capture this kind of unstructured,sort of JOSN format.
so sort of like HTTP post request to the applictaion server which will storing do any sort of processing, to this sort of general lines which we can dive a little bit deeper but it will end up storing into the profile DB,and like I mentioned earlier like this is also where we would be taking to encoding service for like the uploading service.
so this is pretty much like the general design flow for the profile creation,and then I think I will go on to the next part which feed and recommendation,and I think after we've gone kind of all the core components we can go back end talk about like scalability adding blancer or cache in memory.
so we don't want to recommend people who are kind of the globe,and we also want to show users,like metioned earlier they could be 50 millon registered users and them are within area but they are not actully actively using sow we do want to make sure that we're showing up ative users the feed recommendation and we also want to make sure we between kind of like showing too many matches not matches for each user,so what that means sort of like if one user too many matches,then we kind of want to make sure they are not getting recommended even more and some people not getting any matches,we want to make sure we're focusing on adding more kind of like,i guess like reducing more requirement,so reducing some of or kind of some up those requirements when it comes to recommendation .
it like product inspired that your're going in?
yeah,and this cloud be kind of thing but kind of list out,and maybe some sort of like,so i think we want to prioritize either kind of like pretty fast .
recommentation,there's also like new recommendation showing up,so low latency versus kind of real-time match recommendation i just say so this is kind of like where do we want to prioritize do we want to make sure that's there's more recommendations coming in once a user kind of like swipe all that their profiles or do we want to make sure there are more users of the kind of newly created profiles that are showing up so i think this is something that we can discuss a little bit more I'm more leaning towards low latency just because I feel like it doesn't really matter if we're kind of late to some of the newly created profile if we eventually will show them.but that is something that we can decide.
注:红色表示漏听或者听错