System Design Mock Interview: Design TikTok ft. Google TPM

design tick-tock hey everyone i'm here today with adam and today we'll be doing a mock system design interview i'm really excited to have adam uh in this video um adam do you mind just introducing yourself and telling us a little bit about what you work on sure um hi my name is adam i work on cloud engineering and back-end systems uh currently at oracle but i'll be moving over to google soon awesome um yeah we're really excited to jump into a practice system design interview today um the question that we'll be doing is design tick-tock okay cool design tick tock well this is a phone i i actually have never used tik tok um great uh so maybe uh we can start by just quickly kind of if you could give me a i have an idea obviously i know what it is but um if you could just kind of give me a quick overview of what we're looking for and maybe be a little bit specific on the um portion of tiktok we're wanting to focus on awesome yeah um so yeah high level overview of tick tock is it's a mobile app so it's for video sharing between users and the basic idea is you're able to upload a video to tick-tock and then you're able to view a feed of videos so you see one video a time you scroll up you see the next video you can follow users so you see their videos that they post and then you can also like perform actions on those videos like favoriting them or commenting on them i think so those are sort of the basic things we'll want to support cool all right that makes sense um so i'm sorry i'm just going to take a minute and kind of jot down some notes real quick sounds great um yeah in the meantime i'll switch over and just screen share here into our whiteboard cool so um uh so it looks like tiktok is a mobile app um if it's okay with you i think i'm just gonna focus on sort of the back end infrastructure and not so much go into the mobile app portion um just because i think there's a little bit more feature-rich detail there the back-end system um yeah sounds great from what i can see the the first thing i kind of want to dive into are sort of these these functional um requirements um and when i say functional requirements i just kind of mean you know the sort of top level buckets of work that we're wanting to um to look into so the first thing from what you explained to me was upload videos right so a user from their mobile device or really in theory since we're just dividing the device in the back end if it's okay i'm going to assume that we're just going to create an api that is sort of um client agnostic that's gonna accept um uh user data to upload videos so we're gonna kind of think sort of section one here if i was gonna write this up these um functional i'm just gonna say number one here is upload videos and so um when we upload videos uh these videos um are they're sort of time boxed right it's sort of the same way of instagram like they only are about 15 seconds each is that right yeah and yeah i can we can assume they're you know 30 seconds to maybe a maximum of like a minute long okay so max one minute cool um and i'm also assuming that uh if i'm uploading videos um there's also would there be like text associated with that like it's sort of like it with instagram or facebook where you can upload a photo but you can also like tag and add like text and you know things like that yeah that's a good question yeah let's assume like yeah you can uh you can add like a comment or caption to it um we don't need to get maybe into the details of like tagging and how that would work but yeah maybe some text data associated with it okay cool upload i deleted what i was writing here upload so let's say uh video plus text cool and then kind of number two here what i'm thinking is um you said uh view feed so when i think about you know viewing the feed what we're doing is we're aggregating uh and correct me from wrong we're talking about aggregating videos from is it people i follow only is it people i follow plus sort of like i know that tick tock has this special algorithm that they use to to grab recommended videos um would it be kind of like can can i assume there's sort of a mixture of those two things yeah i think it's i think that's a good question um uh for simplicity we could focus maybe on uh videos of people you follow but would be interested in hearing about sort of how you would sort of create like a trending or like video recommendation as well uh for the purposes of this do you want me to include like an ability for me to comment like uh videos um as part of that functionality yeah let's let's try to build out how we would like favorite videos um and maybe like follow particular creators okay cool so um yeah that's actually my next functional requirement here which is kind of follow users um so favoriting following uh commenting forwarding i don't know if they allow that but just i'll just kind of bucket that as like a sort of video interaction um end point sure cool all right so that kind of covers these as like the general functional requirements um so really quickly i just want to talk about these non-functional so really non-functional what i mean by that is kind of like let's start with availability availability uh latency um and scale so um so it sounds to me like i'm gonna make an assumption here that this is a hot it needs to be a highly available system um just simply because of the the way the scale of the users that are going to be using it um sounds like it's going to be a lot and it really um because it is serving videos it does need to be highly available so i'm just going to say roughly you know highly available i'm going to say around 99.999 um if that's correct that sounds about right for you yeah that sounds great because like you know there's always these trade-offs right like when we talk about uh when i'm thinking about how i'm going to design a system i'm just trying to understand like if it's not super high like if it's maybe less doesn't need to be as highly available maybe there's certain things we can do to balance our our budget and how we're going to budget for our compute resources and that sort of thing so cool um so uh also think about latency um you know the one good thing is we're from the sound of it since it is a mobile device it sounds like we can kind of cache a lot of the content on the device itself um so when we initially pull stuff we'll be able to obviously get the top level stuff really quickly but after that we can kind of be pulling stuff in the background so we do it sounds like we have a little bit of leeway there is that sound about right to you yeah that sounds good um i think maybe later on we can talk a little bit about the latency or um how this would differ across different features like upload versus download and and how to think about that yeah okay i'll just put tbd for that um cool and then um uh scale so can you just give me a rough estimate on like um if we if we're talking about uh users um do you have any kind of idea how many users we're talking about here like in a day yeah in a day um let's say we want to support like you know a million active users in a day okay so a million daily active users um cool so i'm just going to do a couple of estimates here now that we're talking about this so just this gives me an idea of you know how i'm going to store everything so we said max here for the video videos were about um let's see one minute i'm just going to make a quick assumption and say that a minute of compressed h.264 video is about five megabytes that sounds about right to you um i think it sounds like you know um and then maybe we can say each user is uploading two per day equals 10 megabytes per day per day per user i'm not going to get too much into this yet i just want to get a rough idea for the big big chunk here which is videos you know the rest of it user metadata is going to be minimal i think it's going to be you know 1k um per user per day um i think that's a pretty good estimate roughly uh cool okay cool so i think with all that um is there anything else i'm kind of you can see that i'm missing here does that seem like a rough good sort of overview of the system that we're trying to tackle here um yeah this seems like a good overview i think we can uh we can dive in now okay um cool so i think uh i'm gonna start with just kind of a couple of api endpoints just to get a wrap my head around so um i think what i'd like to start with is um uh we'll just start here and we'll say um upload video just because we have it really that's going to be um and if i if i talk about i don't get too much of the parameters of it but if i talk about the database schema that sort of backs that um really our user object is going to be something along the lines of we're going to have some sort of user id and that's going to be like a uid we're going to have a um some sort of video video link that's actually i'll get to that later but i think that's going to be once we upload the video we're going to want to store i think in some sort of blob storage like s3 so this will be a fully qualified link to that um to that object so this would be like a url um uh and then maybe meta this would be just like metadata this would just be string string data so that's kind of the first endpoint i'm thinking um so let me just kind of go into that real quick i'm not going to get into much of the user detail stuff here just because i think that's sort of a solved problem i think we can get to that if we have time but for the scope of this i'm not really going to talk too much about it um so i'm just gonna take a minute and kind of think this through okay cool so i think um uh obviously we're gonna want some sort of database right to to back this um and this is this is gonna be where we store this table um so i'm assuming this is going to for right now i'm just going to make an assumption this is going to be a relational database postgres whatever flavor or relational database you so choose so upload video is going to send this this object to the relational database could you um just briefly sort of talk about maybe the differences between a relational database versus another type of database and and why we might want to use this yeah so um like a relational database versus like a no sql database for example relation is going to be a little bit more structured in the in the so typically you'll use relational databases for um for things like uh you know user data objects linking different tables together so for example you can have like a single user that has many videos so you would have that many video objects and those can be stored in two different tables and you can do sql queries against those things like nosql databases are really good for unstructured data like log data things like that so a little bit more free form in nature not as you know not as structured in the sense that you're going to be querying that data and doing a lot of joins to it you're kind of just going to be more like free form searching for key values keys and values inside that data so um yeah in this case you know relational database can be relational database can be a lot more uh strict but it can also be more more space and speed efficient for specific queries um so yeah i think that makes sense here um so yeah like i think what we do is upload the video object to this database oh sorry rather this would actually just be the video data right it would be the best way to describe this uh the video i just say the video table right so this is going to send to the video table the idea here is that this is just the data because what we're then going to want to do is send the actual video object to some sort of cloud bucket like i mentioned before so um like uh s3 just use this cloud thing so like um this would be like a blob store um the idea here is that yeah the video itself actually lives here and then in this table we have a link to that so um we're going to be running like a post oops we're going to be running a post to this api endpoint this upload video endpoint so i'm running out of space let me just move all this over a bit um this would be my video plus my user information so yeah the upload video accepts the video and the user information we um save it in the table we upload it to blob storage and then we're going to return like some sort of um you know some sort of 200 response which is what the api would respond with to the app itself saying that the video went through correctly um so that kind of handles our upload section it's pretty straightforward for the upload section there is there any questions about that or did you have anything i think i missed there um no i think that makes a lot of sense um yeah we have the sort of overview of uh where the video goes where the metadata goes and how the app would sort of make that request so i think that makes sense cool awesome um so let's talk really quick about the view feed so um this will be kind of a similar endpoint view feed and what this is actually going to be is a get request so when you open up the app sorry so when you open up the app um i think would we want to load this content um right when the application opens like i'm guessing we want to start pre-loading as much as we can um ahead of time so that the user isn't waiting too much for videos to load right yeah i think we'd want to do that um insofar as it would let us you know view videos faster but maybe not so much that it would uh you know maybe use up user bandwidth and things like that yeah i think maybe like the top like whatever the first like three videos for example we'd want to just grab those as quick as possible because the reason i asked that is i think it would make sense to sort of like have some sort of like uh redis cache over here um some sort of cache whatever it is and the idea here would be that we actually preload a list of like user um like the top 10 videos that we're going to load for the user before they even get to the view feed page so like if a user with a specific user uuid hits this view feed we're going to go to this cache that's already pre-built and we're going to grab those top videos that are already pre-selected so like for example this uuid would give me this would respond with like you know 10 videos video links rather that are associated with that user id and the the links for the blob storage so that the app would then be grabbing them from the blob stores like right away does that make sense yeah that makes sense um yeah that's super interesting can you like tell me a little bit more about how the cache would work or yeah so i'm actually thinking about a service here um in the back background that would run um so this would sort of like be a pre-cash service service pre-cash service um and this would just kind of run um on like a like a schedule but also just like maybe on demand um uh something like that and what it would do is it would compile playlists for users and and pre-cache them so uh it could be potentially like we could sort of base it on when the user actually goes and act and does the get request um that we sort of preload it for the next one or we just do it in the background there's there's a couple of um strategies we could use there what i'm trying to get away from is relying too much because from what i can tell this system seems very read heavy right like there's a lot there's gonna be a lot of reading going on so in addition to having this main database which i'll get to scaling i think in a bit but i think for this main data this main database we're also going to want to have some sort of read worker which would be like a read-only database and the reason being we don't want to create too much load on this single database that's it's accepting these uploads we want to have something that's managing the reads so in fact i would actually do something like this where um the secondary is pulling from the primary uh um and this is used for read-only which builds the pre-cache which loads the cache which then when the view feed gets hit it loads it instantly right yeah at least the the the query right so does that make sense yeah that that makes a lot of sense um i think getting back to one of the first questions about latency can you talk a little bit about how introducing this cache would sort of affect um latency in the system and seeing updates and things like that yeah for sure so um one thing we would need to consider is how quickly we want like if i don't know if actually the video that i upload i don't think that would show up in my feed and if so yeah i think what so this feed is basically a curated list of videos so i think the point here is that because i know that tick tock has like a special algorithm they use to populate your feed so i'm trying to get rid of all that happening at the moment of get like at the moment of loading the app i'm trying to have it pre-built right so that right away we're getting what we need from the back end and not having to wait for some sort of service to compile that on the fly plus this also solves a little bit of our scaling issue because if we have situations where if you can imagine tick tock has a million users if what if one million users all get on the same time and run the same exact query we could really kill our databases because we're running all these queries at the same time we can also up that latency so you can solve that with some like you know like auto scaling groups but even auto scaling groups take time to sort of spin up so that's kind of the thing i'm thinking about here but the real the real key here is i think i just noticed that this seems very read heavy so i was trying to get to the point where those reads were sort of managed on their own yeah i think that's a great great insight cool i think that kind of handles the view feed for the most part yeah i feel pretty good about that last piece here would be favoriting videos i think we would have um just another end point here where we would um put another one in there yeah so i think we have another one um and this would just be like i'm just going to call this um user activity maybe or something like that this would be that's a little bit generic but i'm going to speed through this we're in a little bit long time i try and name it something better in the real world like something more descriptive of what it actually did but the idea here is that um um when i hit the user activity this is like follow this is um uh doing um liking videos that sort of thing and i apologize i'm actually going to just move this around a little bit so that i can get to my database cleaner yeah yeah just move this down a bit so yeah the the idea behind user activity is is literally just going to hit this rdp um the database and so for my uh i'd actually have a different table here i'd have like a some sort of um let me just put this over here put it right here for now so this table would look something along the lines still have a user id and a uuid um i think we would have um so uh yeah i think i think this would be a like a followers like a um like a user activity table and the idea here would be um going to need a couple of keys here so following is actually going to have to be a foreign key to another table um because we're going to have for any one user we're going to obviously be following multiple other accounts right so um we're going to need another table in there that's got a list of um user ids that i'm following user accounts um in addition to that we're going to want likes so we're going to want to store another i think another foreign key to like a videos table so i'm assuming we like assuming if each account has a like a table of videos like we're seeing up here um we would basically have sorry i think i missed something here we're probably going to want to have a um like a video uuid like a video id and this would be a uid field here so that i can key to this video id and say that that's a list of like the likes of the likes that i'm um liking and then this all feeds later into the precache service algorithm which i'm not going to get into but i think that's important to store so basically whatever activity i have all this user activity is going to hit the database um i'm going to store this up here for now it's going to hit this database um and add that to my to my to this table right so i'm now following this user i'm liking this video etc so that if i ever needed to like run a get request which sounds like the precache service we'll actually need to run um some sort of request against user activity or or some sort of um maybe we have like an internal service that manages that i'm not sure um but yeah i i'd have an api that would that would return all the users likes and followers essentially is what i'm getting at and maybe that's a get request here from from the user activity but that's sort of the rough idea of what i'm thinking for that does that make sense from sort of a flow perspective yeah that makes sense um awesome okay well yeah i think we've got sort of the main interactions here we've we've got most of the features sort of structurally built out i'd be curious as sort of a follow up here what do you think would be sort of the bottlenecks of the system if you were to for example like 10x the traffic one day or something like that to really scale things up yeah absolutely um so first thing i have to think about is just regions if we're thinking about um if we're thinking about having this uh multiple versions of this in in regions like regional data centers we might want to consider that just geolocating so my first inclination is just whatever user we're going to put the user behind some sort of basically all these api endpoints are going to want to go behind some sort of like cdn right content delivery network so like akamai or something like that because um like the minute we grab a video for example um let's say let's say in a lot of situations where we really 10x traffic it's typically in these scenarios around like you know somebody famous sends out a video right and we have they have 10 million followers and everyone wants to view the video so the idea behind the cdn is the minute the first person grabs it the cdn caches it locally um behind the on the cdn system so that all the users who are grabbing it are just grabbing it from the cdn and cdn is doing like uh you know a routing to the local the closest node so that the the internet traffic isn't always hitting my system my blob storage it's only hitting the cdn so that sort of fronts because like obviously these videos are relatively big in the scale of like in the site when we're talking about 10 million users times um you know five megabytes per video that's a pretty uh substantial number to deal with so putting a cdn behind that in front of that's important um i think having a load balancer uh in front of these api endpoints as well we'll we'll do thing one we'll just we'll do a couple things number one um number one it's going to let me um commit to this highly available non-functional requirement because these api endpoints can be scalable and we can do things like have multiple um multiple deployments so multiple services running so this the load balancer is picking which one of these services is available at any one time and and you know scaling them accordingly or sorry um routing traffic accordingly so a or b for example um so it's not only is it balancing between the two but it also lets you do things like zero down time deployment so if we have to update this uh software the the back end software that's running this we would uh flip all traffic to b and only allow b to be serving traffic while a is down and getting updates right um and i a to b is very simple simplistic view that could be hundreds of compute instances but that's sort of the idea there so that's kind of where i see the bottleneck like i said database is always kind of a bottleneck i think so we'd have definitely like sort of a main write database with read-only um workers that manage sort of the get requests and these would also be in some sort of auto scaling group so that we could scale them up as needed same thing with the precache service um i think we have a pretty good idea once we got more in detail with this how our pre like what what we needed and what as far as like timing and requirements around what we need for um we'd have a pretty good understanding so i don't know how like auto scaling this would have to be it might just be able to be like set in stone or roughly equivalent to that so that we know ahead of time um cash similar similar situation caches are pretty scalable and things like that the one last thing i think about is this write database so if we were to 10x traffic to this we'd want to consider doing some sort of database sharding so that we are and we'd have some sort of database shard service here in front of this where um where we are basically uh sorry let me just clean this up a bit basically so this sharding service sits in front of the right the um all the rights and it picks it's like a load balancer for databases essentially and it picks um which database it's going to go to based on there's all kinds of sharding um algorithms or or strategies you can do things like the sim though the simplest version of that is like if you took maybe like a region so all us requests go to this database all uk requests go to this database you can do things like that um yeah so that's kind of the way i would picture it because that will help us to split the load between these databases yeah awesome um yeah well i think we've got uh we jumped into some details there i think overall we've got all the pieces sort of in place and i think this is a pretty good stopping part um do you have any sort of last things you would add to this uh before we before we sort of wrap up um no i i think just the something i might if i had a little more time i'd maybe get a little bit more into the precache service because i think it might need its own almost separate like database structure and things like that but i think like i said i don't want to get too much into the weeds with the tick tock specific like other algorithming kind of stuff i think just kind of keeping it saying that this exists somewhere and we would just use it is good enough for the purposes of this interview so no i feel i feel pretty good about it awesome um all right well yeah let's call it here and um yeah so just sort of recapping what we went over so we talked about designing the api we talked about database structure we talked about you know different microservices and load balancing and things like that i thought overall like you did a really awesome job of really clearly communicating all these ideas and also you know sort of jumping in and providing extra knowledge about the specific things um even when i asked like a follow-up question or even without asking i feel like you really jumped in and sort of showed you had mastery over like all of these topics which was really awesome and even though this is sort of a little bit of a condensed version of this i feel like you could have gone multiple layers deeper unlike any of these topics so it really shows me that you know what you're talking about but yeah what did you think overall yeah i think it's it's it's always um interesting trying to design something that you've never used so we're sort of having to make a couple of assumptions on you know knowing i know facebook i know instagram so i kind of understand those but um so making some assumptions on how uh it's used by people um really kind of helped but yeah i thought it went well well thank you so much adam and good luck to everyone on your system design interview you

Channel: Exponent

Views: 146,549

Rating: 4.8839741 out of 5

Keywords:

Id: Z-0g_aJL5Fw

Length: 33min 11sec (1991 seconds)

Published: Wed Jan 20 2021