System Design Mock Interview: Design TikTok ft. Google TPM

[00:00] Design TikTok. Hey everyone, I'm here today with Adam, and today we'll be doing a mock system design interview.

[00:12] I'm really excited to have Adam in this video. Adam, do you mind just introducing yourself and telling us a little bit about what you work on? Sure. Hi, my name's Adam. I work on cloud engineering and backend systems, currently at Oracle, but I'll be moving over to Google soon.

[00:30] Awesome. Yeah, we're really excited to jump into a practice system design interview today. The question that we'll be doing is design TikTok.

[00:42] Okay, cool. Design TikTok. Well, this is a fun, I actually have never used TikTok. Great. So maybe we can start by just quickly kind of, if you can give me a, I have an idea, obviously.

[00:55] I know what it is, but 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 portion of TikTok we're wanting to focus on. Awesome.

[01:07] Yeah. So, yeah, high-level overview of TikTok 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 TikTok

[01:19] and then you're able to view a feed of videos. So you see one video time, you scroll up, you see the next video. You can follow users, so you see their videos that they post

[01:31] and then you can also 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.

[01:43] so I'm just going to take a minute and kind of jot down some notes real quick sounds great yeah in the meantime I'll switch over and just screen share here into our whiteboard cool so

[01:55] so it looks like TikTok is a mobile app if it's okay with you I think I'm just going to focus on sort of the back end infrastructure and not so much go into the mobile app portion

[02:08] just because I think there's a little bit more feature rich detail there, the backend system. Yeah, okay. From what I can see, the first thing I kind of want to dive into are sort of these functional requirements.

[02:25] 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 look into. So the first thing from what you've spoken to me was upload videos, right? So a user from their mobile device,

[02:39] or really in theory, since we're just dividing the back end, that it's okay, I'm going to assume that we're just going to create an API that is sort of client agnostic that's going to accept user data to upload videos.

[02:55] So we're going to kind of take sort of section one here. If I was going to write this up, these functional, I'm just going to say number one here is upload videos. and so

[03:07] when we upload videos these videos they're sort of time boxed right? It's sort of the same way as Instagram

[03:19] like they only are about 15 seconds each, is that right? Yeah, we can assume they're 30 seconds to maybe a maximum of like a minute long Okay, so max one minute

[03:31] Cool and I'm also assuming that if I'm uploading videos there's also would there be like text associated with that like sort of like

[03:43] with the 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 you can add like a

[03:56] comment or caption to it 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.

[04:09] Upload. So let's say video plus text. Cool. And then kind of number two here, what I'm thinking, is you said view feed.

[04:21] So when I think about, you know, doing the food, what we're doing is we're aggregating, and certainly if I'm wrong, we're talking about aggregating videos from, is it people I follow only?

[04:33] Is it people I follow plus sort of like, I know that TikTok has this special algorithm that they use to grab recommended videos. Would it be kind of like, can I assume there's sort of a mixture of those two things?

[04:46] Yeah, I think that's a good question. For simplicity, we could focus maybe on videos of people you follow, but would be interested in hearing about how you would sort of create a trending

[04:59] or video recommendation as well. For the purposes of this, do you want me to include an ability for me to comment, like videos as part of that functionality?

[05:14] Yeah, let's try to build out how we would like favorite videos and maybe like follow particular creators. Okay, cool.

[05:26] So, yeah, that's actually my next functional requirement here. which is kind of follow users. So favoriting, following, commenting, forwarding. I don't know if they allow that, but I'll just kind of bucket that

[05:38] as like a sort of video interaction endpoint. Sure. Cool. All right. So that kind of covers these as like the general functional requirements. So really quickly,

[05:50] I just want to talk about non-functional. So really non-functional, What I mean by that is kind of like let's start with availability,

[06:06] availability, latency, and scale.

[06:23] So it sounds to me like, I'm going to make an assumption here that this needs to be a highly available system, just simply because of the scale of the users that are going to be using it.

[06:39] Sounds like it's going to be a lot, and it really, because of the serving videos, it does need to be highly available. So I'm just going to say roughly, you know, highly available.

[06:51] I'm going to say around 99.999%. If that's correct, if that sounds about right for you. Yeah, that sounds good. Because, like, you know, there's a lot of these trade-offs, right?

[07:03] Like when we talk about, 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, 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 budget

[07:18] and how we're going to budget for our compute resources and that sort of thing. Cool. So I also think about latency. You know, the one good thing is we're, from the sound of it, since it is a mobile device,

[07:30] it sounds like you can kind of cache a lot of content on the device itself. 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.

[07:42] So it sounds like we have a little bit of leeway there. Does that sound about right to you? Yeah, it sounds good. I think maybe we can talk a little bit about the latency or how this would differ across different features,

[07:56] like upload versus download and how to think about that. Okay. I'll just hit TVD for that. Cool. And then scale. So can you just give me a rough estimate on, like,

[08:09] If we're talking about users, do you have any kind of idea how many users we talking about here like in a day Yeah in a day Let say we want to support like a million active users in a day

[08:27] Okay. So a million daily active users. Cool. So I just want to do a couple of estimates here now that we're talking about this. So just gives me an idea of, you know, how many store everything.

[08:41] So we said max here for the video. Videos were about, what's the one minute. I'm just going to make a quick assumption and say that a minute of compressed HG64 video is about five megabytes.

[08:58] That sounds about right to you. And then maybe we can say each user is uploading two per day equals 10 megabytes per day per user.

[09:15] I'm not going to get too much into this yet. I just want to get a rough idea for the big chunk here, which is videos. You know, the rest of the user metadata is going to be minimal. I think it's going to be, you know, 1K per user per day.

[09:27] I think that's a pretty good estimate roughly cool okay cool so I think with all that is there anything else you can see that I'm missing here

[09:39] does that seem like a rough good sort of overview of the system that we're trying to tackle here yeah it seems like a good overview I think we can dive in now okay cool so I think I'm going to start with just kind of a couple

[09:52] of API endpoints just to wrap my head around so So I think what I'd like to start with is we'll just start here and we'll say upload video because we have it.

[10:09] Really, that's going to be – if I talk about – I don't want to get too much into parameters there, but if I talk about the database schema that sort of backs that, Really, our user object is going to be something along the lines of, we're going to have some sort of user ID.

[10:31] And that's going to be like a UID. We're going to have some sort of video link.

[10:44] 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 it. I think there's some sort of blob storage, like F3. So this will be a fully qualified link to that object. So this will be like a URL.

[11:02] And then maybe meta. This will be just like metadata. This will just be string data. So that's kind of the first endpoint I'm thinking.

[11:14] 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.

[11:30] So I'm just going to take a minute and kind of think this through.

[11:42] Okay, cool. So I think, obviously, we're going to want some sort of database, right, to back this. And this is going to be bloody store, this table.

[11:58] 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. Post that, whatever flavor of relational database you so choose. to upload videos and send this object to be their relational database.

[12:18] Could you just briefly sort of talk about maybe the differences between a relational database versus another type of database and why we might want to use this? Yeah, so like a relational database versus like a no SQL database, for example.

[12:33] Relation is going to be a little bit more structured in the data. So typically you'll use relational databases for things like user data objects linking different tables together.

[12:46] 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 sort of two different tables. You can do SQL queries against those.

[12:58] 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.

[13:16] You're kind of just going to be more like free-form searching for key values, keeping values inside that data. So, yeah. In this case, you know, relational database can be a lot more strict.

[13:29] but it can also be more space and speed efficient for specific queries. So, yeah, I think that makes sense here. Yeah, like I think what we do is upload the video object to this database.

[13:44] Oh, sorry, rather, this would actually just be the video data, right? It would be a better way to describe this. The video, I didn't say the video table, right?

[13:59] 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.

[14:14] So like S3. It's a cloud thing in there. So like this would be like a blob store. The idea here is that

[14:26] the video itself actually lives here and then in this table we have a link to that. So we're going to be running a post to

[14:38] this API endpoint, this upload video endpoint. I may have space. Let me just move all this over a bit.

[14:54] This would be my video plus my user information. So, yeah, the upload video accepts the video and the user information. We fill it in the table. We upload it to the blob storage.

[15:06] And then we're going to return, like, some sort of, you know, some sort of 200 response, which is what the API would respond with to the app itself, saying that the video recorded correctly.

[15:18] 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 missed there? No, I think that makes a lot of sense.

[15:31] Yeah, we have the sort of overview of where the video goes, where the metadata goes, and how the app would sort of make that reflect. So I think that makes sense. Cool. Awesome. So let's talk really quick about view feed.

[15:46] So this will be kind of a similar endpoint, view feed.

[15:58] And what this is actually going to be is a get request. So when you open up the app, so when you open up the app, I think, would we want to load this content right when the application opens?

[16:15] Like, I'm guessing we'd want to start pre-loading as much as we can 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 insofar as it would let us, you know, view videos faster,

[16:31] but maybe not so much that it would you know maybe use a user bandwidth or 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.

[16:44] Because the reason I ask that is I think it would make sense to sort of, like, have some sort of, like, redis cache over here

[16:56] some sort of cache, whatever it is and the idea here would be that we actually preload a list of user, like the top 10 videos

[17:11] 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 view ID hits this view feed, we're going to grow this cache that's already pre-built, and we're

[17:23] going to grab those top videos that are already pre-selected. So, like, for example, this UUID would give me, this would respond with

[17:35] like, you know, 10 videos, video links, rather, that are associated with that user ID, and the links for the blob storage, so that the app would then be grabbing them from the blob storage right away.

[17:48] Does that make sense? Yeah, that makes sense. Yeah, that's super interesting. Can you, like, tell me a little bit more about how the cache would work or? Yeah. I'm actually thinking about a service here in the background that would run.

[18:03] So this would sort of like it would be a pre-cache service. Pre-cache service. And this would just kind of run potentially on, like, a schedule,

[18:15] but also just like maybe on demand, something like that. And what it would do is compile playlists for users and pre-cache them. So it could be potentially like we could sort of base it on when the user actually goes

[18:32] and does the GET request that we sort of preload it for the next one, or we just do it in the background. There's a couple of strategies we could use there. What I'm trying to get away from is relying too much.

[18:46] From what I can tell, the system seems very read-heavy. There's going to 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,

[18:58] but I think for 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.

[19:15] Except you need to upload. We want to have something that's managing the reads. So in fact, I would actually do something like this, where the secondary is pulling from the primary,

[19:27] and this is used for read only, which goes to pre-cache, which loads the cache, which then when the view feed gets hit, it loads it instantly. Right, yeah. At least the query.

[19:40] So does that make sense? Yeah, that makes a lot of sense. 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 latency in the system

[19:52] and being updated and things like that? Yeah, for sure. So one thing we 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.

[20:06] And I think we've got, so this feed is basically a curated list of videos. So I think the point here is that, because I know that TikTok has like a special algorithm they use to populate your feed.

[20:20] 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.

[20:36] Plus, this also solves a little bit of our scaling issue because if we have situations where you can imagine TikTok has a million users, if one million users all get on at 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.

[20:53] And we could also up that latency. So you can solve that with some, like, you know, auto-scaling groups. And even auto-scaling groups can take time to sort of spin up. So that's kind of the thing I'm thinking about here.

[21:08] But 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 insight.

[21:20] Cool. I think that kind of handles the new feed for the most part. Yeah, I feel pretty good about that. Last piece here would be favoriting videos. I think we would have just another endpoint here where we would –

[21:37] so I think we'd have another one, and this would just be like – I'm just going to call this user activity maybe or something like that.

[21:50] This would be – that's a little bit generic, but I'm going to speak through this. We're in a little bit long time. I try and name it something better in the real world, something more descriptive of what it actually did.

[22:02] But the idea here is that when I hit the user activity, this is like follow, this is doing liking videos, that sort of thing.

[22:14] 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.

[22:26] Let's do this down a bit. So yeah, the idea behind user activity is it's literally just going to hit this RDB, the database. And so for my – I'd actually have a different table here. I'd have like some sort of – let me just put this over here.

[22:43] I'll put it right here for now. So this table would look something along the lines. It'll have a user ID and a UUID. I think we would have so yeah I think

[22:57] I think this would be like a followers like a user activity table and the idea here would be we're going to need a couple of keys here so

[23:09] following is actually going to have to be a form key to another table because we're going to have, for any one user,

[23:25] we're going to obviously be following multiple other accounts, right? So we're going to need another table in there that's got a list of user IDs that I'm following, user accounts.

[23:37] In addition to that, we're going to want likes. So we're going to want to store, I think, another foreign key to a videos table.

[23:49] So I'm assuming each account has a table of videos like we're seeing up here. We would basically have

[24:01] sorry, I think I missed something here. We're probably going to want to have a video UID. Like a video ID. This would be a UID field here

[24:13] so that I can key to this video ID and say that there's a list of the likes that I'm liking. And this all feeds later into the pre-cache service

[24:25] algorithm, which I'm not going to get into, but I think that's important to store. So basically whatever activity I have, this user activity is going to hit the database. I'm going to hit this database and add that to

[24:41] this table. So I'm now following this user. I'm liking this video, etc. So that if I ever needed to run a get request which sounds like the pre service will actually need to run some sort of request against user activity or some sort of

[24:59] maybe we have like an internal service that manages that. I'm not sure. But yeah, I have an API that would return all the users' likes and followers, essentially, as I'm getting at. And maybe that's a get request here from the user activity.

[25:13] 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? Yes, that makes sense. Awesome. Okay, well, yeah, I think we've got sort of the main interactions here.

[25:26] 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

[25:40] or something like that to really scale things up? Yeah, absolutely. So first thing I have to think about is just regions. If we're thinking about having this multiple versions of this in regions, like regional data centers,

[25:58] we might want to consider that just via locating. So my first inclination is just whatever user, we're going to put the user behind some sort of,

[26:10] basically all these API endpoints are going to want to go behind some sort of like CBN, right? content delivery network. So like Akamai or something like that because like the minute we grab a video, for example,

[26:25] let's say in a lot of situations where we really connect traffic, it's typically in these scenarios around like, you know, somebody famous sends out a video, right? And we have 10 million followers and everyone wants to do the video.

[26:38] So the idea behind the CDN is the minute the first person grabs it, the CDN caches it locally on the CDN system so that all the users who are grabbing it are just grabbing it from CDN.

[26:50] And CDN is doing like a routing to the local, the closest nodes so that the internet traffic isn't always hitting my system. My blob storage, it's only hitting CDN. So that sort of fronts,

[27:03] because obviously these videos are relatively big in the scale of like, when we're talking about 10 million users times five megabytes per video, So that's a pretty substantial number to deal with.

[27:16] So putting the CDN in front of that is important. I think having a load balancer in front of these API endpoints as well. We'll do a couple things.

[27:29] Number one, it's going to let me commit to this highly available non-functional requirement

[27:42] because these API endpoints can be scalable. And we can do things like have multiple deployments, so multiple services running. So the load balancer is picking which one of these services is available at any one time

[27:56] and, you know, scaling them accordingly – or sorry, routing traffic accordingly, so A or B, for example. So it's not only is it balancing between the two,

[28:09] but it also works to do things like zero downtime deployment. So if we have to update this software, the Batman software that's running this, we would flip all traffic to B and only allow B to be serving traffic

[28:22] while A is down and getting updates, right? And A to B is a very simplistic view. That could be hundreds of computers. That's sort of the idea there.

[28:34] 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 workers that manage sort of the GET requests.

[28:50] 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 precast service. I think we'd have a pretty good idea once we got more in detail with this,

[29:03] like what we needed and what, as far as timing and requirements around what we need for services, we'd have a pretty good understanding. So I don't know how, like, auto-scaling this enough would be.

[29:16] It might just be able to be, like, set in stone or roughly equivalent to that so that we know ahead of time. CAS, similar situation. Caches are pretty scalable and things like that.

[29:31] The one last thing I think about is this write database. So if we were to 10x track it for 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

[29:45] where we are basically – let me just clean this up a bit. Basically,

[30:01] basically, so the sharding service sits in front of the right, all the rights, and it picks,

[30:13] it's like a load balancer for databases, essentially, and it picks which database it's going to go to based on, So there's all kinds of sharding algorithms or strategies.

[30:27] You can do things like – the simplest version of that is, like, if you took maybe, like, a region. So all U.S. requests go to this database. All U.K. requests go to this database.

[30:39] You can do things like that. 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. Yeah, well, I think we've got, 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. Do you have any sort of last things you would add to this before we sort of wrap up?

[31:08] no I think just something I might have had a little more time I would maybe get a little bit more into the pre-cache service because I think it might need its own almost separate like database structure and things

[31:21] like that but I think like I said I don't want to get too much into the weeds with the TikTok specific like algorithm 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

[31:33] the purposes of this interview so no I feel pretty good about it awesome All right, well, yeah, let's call it here. And, yeah, so just sort of recapping what we went over.

[31:45] So we talked about designing API. We talked about database structure. We talked about, you know, different microservices and load balancing and things like that. I thought overall, like, we did a really awesome job of really clearly communicating all these ideas

[31:59] and also, you know, sort of jumping in and providing extra knowledge about the specific things, even when I ask a follow-up question or even without asking, I feel like you really jumped in and sort of showed you had mastery

[32:12] over all of these topics, which was really awesome. 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 on any of these topics. So it really shows me that you know what you're talking about.

[32:26] But yeah, what did you think overall? Yeah, I think it's always interesting trying to design something that you've never used. So I would make a couple of assumptions on, you know, knowing,

[32:38] I know Facebook, I know Instagram, so I kind of understand those. But so making some assumptions on how it's used by people really kind of helps.

[32:50] So, yeah, that's all. Well, thank you so much, Adam, and good luck to everyone on your system design interview.

[33:03] you