We helped write the sequel to "Cracking the Coding Interview". Read 9 chapters for free

An Interview with a Google engineer

Watch someone solve the design youtube problem in an interview with a Google engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.

Interview Summary

Problem type

Design YouTube

Interview question

Design YouTube: 1. Users can upload videos 2. Users can stream(watch) videos 3. Users can search for videos

Interview Feedback

Feedback about Winged Shadow (the interviewee)

Advance this person to the next round?

How were their technical skills?

2/4

How was their problem solving ability?

2/4

What about their communication ability?

2/4

The candidate is knowledgeable on various topics, such as rate limiting, different protocols to connect with the server, etc. However, the candidate spent too much time on topics that are not important, such as capacity planning (spend like 10 minutes but didn't really give out any numbers at the end), rate limiting, different ways to connect with server, etc. I had to interrupt the candidate multiple times to get back on track. Because of this, the candidate wasn't able to finish some major parts of the design - api design, data model (incomplete), database choice, etc. The candidate's design was also missing a very important piece for any video streaming platform, which is the use of CDN. To improve, the candidate should make sure to cover all the major parts of the design first, before dive into any detailed topics. The candidate should look into the following topics: CDN, DASH/HLS protocols, and transcoder

Feedback about Teflon Possum (the interviewer)

Would you want to work with this person?

Yes

How excited would you be to work with them?

4/4

How good were the questions?

4/4

How helpful was your interviewer in guiding you to the solution(s)?

4/4

Interview Transcript

Teflon Possum: Yeah, let's get started. So I will briefly introduce myself and maybe you can give like a quick introduction of yourself as well and then we'll just like jump straight to like assistant side questions. And then I'll leave time for feedback at the end.

Winged Shadow: Thank you. Sure. Cool.

Teflon Possum: So yeah, my name is Nina. I am a senior software engineer at Airbnb, and I was at Google previously. So I've like, you know, interview candidates at both companies, of course. So I know today you are like specifically people like system design interview on Google, so I will pick a question for that. Yeah, so that's about me. How about you?

Winged Shadow: Yeah, about me. I'm a senior engineer at Amazon. I have about like 10 years of design experience. I have upcoming design round at Google. Yeah, I don't feel that I'm completely ready. But I want to check mostly to find where I'm bad at.

Teflon Possum: Yeah, sounds great. Let me toggle the whiteboard here. Can you see the whiteboard?

Winged Shadow: I see main.txt.

Teflon Possum: I think so at the very bottom, there's like a toggle whiteboard. Can you click on it?

Winged Shadow: Very important.

Teflon Possum: You don't see a whiteboard?

Winged Shadow: Yeah, totally whiteboard. Yeah, yeah, okay.

Teflon Possum: Cool, I can see it now. So I'm gonna just type the question here. So basically for today we want to design YouTube and specifically we want to allow users-- oops, wait a sec. Oh, where is it? Sorry. Do design YouTube users. Why am I not being able to use users? Can upload videos and then users... Why users can Stream, watch videos and lastly, user. I don't know why when I type R it keeps going away. Okay, so users can search for videos. Yeah, so we want to support these three basic functions of YouTube.

Winged Shadow: I see, I see. So it's only three post functions. We are not going into like booking ratings.

Teflon Possum: Right.

Winged Shadow: Okay, so it's just like pretty basic video streaming service. There's only three post functions. Basically, I'm talking about this simple file sharing service, except it's in videos. So they upload videos, we have some collection of videos, they can download videos or see not downloads. That's all for now.

Teflon Possum: No, that's not support download, just like streaming.

Winged Shadow: Yeah, yeah, important difference from file sharing service. And they can search for the videos. They search for the videos, what the parameters of the search.

Teflon Possum: Yeah we can start simple, you know, just like they search by title or like, you know, description. and basic stuff.

Winged Shadow: I see basic stuff. So we have some generic text fields like title of the video, name of the video, some maybe description, something like text boxes. If we have title of the video, they upload videos to the title. and we have, say, like millions of users and they upload videos with the title test or my video or something.

Teflon Possum: Yeah.

Winged Shadow: Do you have any requirements, any, like, ideas for the search, how to distinguish between identical titles or we just give search results that is like this my video, this my video, this my video, similar titles, so just like, okay, we have a couple of pages of videos that happen with the same title.

Teflon Possum: Yeah, so I think we can just, we don't have to go into details of that, but basically there's some sort of ranking. just like.

Winged Shadow: Okay, yeah, yeah, yeah. I understand that it's more like a UX question than like release systems question. Okay, in search results, do you want to show any like reviews, thumbnails, stuff like this? Like they do search for like, for example, I don't know, like Shrek. And search results shows them that there are videos with like name, track in the title, and they have some like previews, some like, some like random like frame from the video.

Teflon Possum: Yeah so basically just like how YouTube works, it's gonna show a preview and then the title, basically like some metadata.

Winged Shadow: Okay, okay. Yeah, so we have basic questionality, we talk about search, we talk about upload, like what's image upload interface? They like, once again, we're talking about UX here, but they click some like big plus button, like multicolor plus button, and they go to the page where they have like upload, and they select the file on the computer, and they put some like title, description, and they click upload. That's it. We don't allow them to like choose particular frame to be a dubla.

Teflon Possum: We don't allow them to choose what?

Winged Shadow: Particular frame in the video to be a thumbnail.

Teflon Possum: I see. Oh yeah, I mean they can choose that. I mean YouTube allows you to, you know either you choose it or, you know, YouTube will generate one for you, right? So they can do that if they want.

Winged Shadow: Okay. Then they can stream, they can like pick particular video by like, say like some random ID and they go to the page on this page shows them the video. Okay, let's go to the checklists. Yeah, I have my own checklists. It's not something that I can just do for. Okay. Just because I'm doing design work. so I just like have some design, I do design review for work. Yeah, yeah, so you start with what is the type of application we are doing? We are doing backend for sure, but application. Are we just talking about web pages or it's like some mobile app or something? Right.

Teflon Possum: So I think this is mostly a backend system design question. So we will be focusing on the backend. But obviously it will be great if you can list out what are the APIs the users are going to be called.

Winged Shadow: Quality and performance. So, yes, we are not worried much about front-end. Yeah, front-end can be any and we can—like somebody's using APIs and stuff. Yeah. What would be the estimated like scale, like user base? We are talking about millions of users. If you have something about YouTube killer, you say that yes, you want millions of users, and people will expect millions of users right after the launch, and we expect many millions of users in a year, correct?

Teflon Possum: Yes. So we can—yeah.

Winged Shadow: Yeah, so from the start it's not something private. It's like really we have a target unit for YouTube counterpart. Okay, so do you put any limits on the video size?

Teflon Possum: We can. We don't—there is like some upper limit for uploading video, but like let's just assume in general like on average the video size will be 300 MB per video. You know some video is like smaller, some video larger, roughly in that range.

Winged Shadow: Okay. Because we say that some smaller, some larger, like, do you want to put like upper bounds? We understand your answer, that expectation that on average the—well, we see them—users will upload some like short videos and we expect they would be in this range. Shorts in this case.

Teflon Possum: So when you say short video, I suppose you mean like YouTube Shorts. That's not within our consideration here.

Winged Shadow: I see. Okay, so say we have some, like, reasonable limits so they don't upload terabytes. Okay. Next, do you have any, like, performance availability goals in mind? Like not talking directly about like SLA, SLA, SLA, low KPI, but like what would be acceptable? Say, like, latency, acceptable delay, like they say, “I want to start watching the video,” and they like the page appears and they get some loading indication and then the video starts playing.

Teflon Possum: Yeah, so of course we want the latency to be as low as possible. Latency the user has to the internet—we want to be as close to that as possible.

Winged Shadow: I see. So we want latency to be just minimal. Okay. So. We can go like back-of-envelope estimations for like TPS and required size, but for this mock interview, I prefer to skip it. Just like I don't want to spend time right now multiplying like 10 millions of users, like uploading videos—some of them upload videos once a day, some upload videos like once a year or something. Say, yeah, we went through this exercise, calculated like QPS, calculated like posts rate, calculated view rate. Yeah, we talk about latency, we talk about size limiters, we can talk about rate limiters most likely to prevent those. I'm just saying that I can talk about to see if customers are abusing view feature or post feature or something. We can design some reasonable limits, no more than one upload per... We talk about it. Usually we talk to product manager—like if you say to the customers, “You upload the video and then you decide to delete it and upload again,” you will tell them, “You need to wait one minute before you upload again,” or not.

Teflon Possum: Rate limiting is not that important in this case. I think if we can try to draw out what the high level system design will look like.

Winged Shadow: Okay, let's jump into design then. So. Just like imagining that our page, how we can draw here. You want to type or something? No, I probably start with some boxes. Perhaps.

Teflon Possum: Yeah, select rectangles and then draw. Yeah, yeah. And then you can click inside it to, you know, type. You just have to double click inside it using that cursor to type. Yeah, something like that.

Winged Shadow: Okay. So we have web pages. Yeah, web pages. We will have like landing page. We can design landing page—usually it's some like preset search based on rankings and whatever. We have watch page, we have close page. Okay. We probably have profile page. Yep. Something like that. I'm just like doing my design first to get into features and get you like APIs and components.

Teflon Possum: Okay. Yeah. So.

Winged Shadow: Landing page, watch page, upload page, and profile page. Then we have some data that depends on which cost you are at. Okay. Okay. We will have Users, we'll have videos. Okay, and for in users, we'll have, whoops, my mouse escapes me. In the user, we have ID name, Some other metadata that is like non-functional metadata.

Teflon Possum: Okay. Yeah.

Winged Shadow: Then some like rate data. What's that? Rate is for like rate telemetry. if it's like say users can upload like one video per day and like one video per-- well, let's actually put it on like a rate limiter because we will not say like we don't have any long-lived rate data. And we have probably have something else here, but you look for it maybe later. We'll have videos.

Teflon Possum: Okay.

Winged Shadow: We have ID. We have title. We have user ID. Okay, that's it for now.

Teflon Possum: Okay. Yeah.

Winged Shadow: Okay, I might add something later. Yeah, some like technical stuff, maybe later. Okay, then we will go to components. Components. So the main thing that we're looking here is that video is streaming so it means that user is connected to the system, the client, our web page, watching web page connected to the system. And it gets chunks of the videos, it's like chunks downloads, etc. for the video. Design choices here are like do you. Have. Some web socket connection or do you like something pretty similar to chunked download? There are very little pros and cons and we can talk that actually both of them could work but usually... What are the two choices? Yeah, well, with Websocket you save on establishment the connection. You save some like latency. But so does the work like... What.

Teflon Possum: Kind of, I guess, what kind of application protocol are you going to be using?

Winged Shadow: That's a great question. Thanks for the hint. Yeah. Do you want to use our own application protocol or you want to use. Our. HTTP websockets or we can demonstrate that you also can use HTTP websockets. Yeah, and what our client is doing. Is. Sends a request for string them. Yeah. And in case of it will be actually. Yeah. Right. If.

Teflon Possum: If you watch. Yeah. Yeah. Yeah.

Winged Shadow: All right. Look, we can potentially use another HTTP. Approach. It's possible. There are just no not much reasons for to not to use HTTP.

Teflon Possum: Okay. Yeah.

Winged Shadow: Because HTTP gives you a lot of useful abstractions and say designing your own binary protocol to replace HTTP is technically possible, but in practice it's not worth it. There is not much benefits.

Teflon Possum: I mean.

Winged Shadow: Except that your own protocol you can optimize it a little bit.

Teflon Possum: But like YouTube. Yeah. So Google, I mean, YouTube only accepts as EV protocol, right? So you don't have a choice. I know in general it's not.

Winged Shadow: Well, yeah. If the design questions you design exact copy of YouTube using the same. Same. Design decisions as YouTube, then, like probably the question is. how YouTube works. Yeah, do you know how YouTube works? And if we are like breaking pros and cons of designing a system that looks like YouTube but maybe works different, then it was saying that there might be some like use cases where different approach also possible. But okay, let's just like skip this. clinical discussion. Stick with HTTP. Yeah, maybe just like discuss benefits of web circuits against HTTP requests. With web circuits, you establish a connection with the IP on load balancer. And from load balancer, you get to one of the API servers. And from API server, you stream the content. And. Advantage is that you the flow control is controlled by the backend. Without. Any flow control protocol. Just at the rate of streaming, the API server sends a chunk of the content to the client. If client detects something wrong, or something, the client can reestablish the connection, perhaps go to different HTTPS server and resume streaming from there. Yeah. The. Benefit of using HTTP requests, like a chunked download, is that Client connects to different API servers, so maybe like even different load balancers, and requests chunks from those different servers. I would say the benefits of spreading client requests across different servers. Just token generic here, not saying it in details. The benefits of distributing requests for the chunks among different API servers, different load balancers are not so great. To. Implement the flow control on the client. Yeah, because here the client controls the flow. Client says, I'm ready for the next chunk of the video and it gets separate requests with overhead of establishing new connection. exchanging metadata, going through authentication and getting the chunk. This web socket, it's a sticky session, but if something goes on, clients can just create a new connection and here the flow control is Yeah, so I think we have the cheap request. With the cheap request, you have like a load a little bit more evenly distributed because you have.

Teflon Possum: Sorry, sorry to interrupt, but I think there's like lots to cover and I think we should really try to draw like the, you know, the overview of the system because like, you know, nothing is like written like drawn right now, right?

Winged Shadow: Shush, shush, shush. Yeah, sorry for okay, so we have components, we have clients, some GS on the page. We have some DNS, we have load balancers. Some. Of them. Yeah. We have FHA server. And we have We have user DB, we have Video DB and we have BLOB storage. Why we have BLOB storage? Because we have video DB to store video metadata and the body of the video, the BLOB should be in some object storage. similar to S3 or something? Okay, what I'm forgetting here? Yeah. We have talked about some rate limiters. There are. Multiple places where we can put them. Typical it's to put here, you can load Bouncer on PPA server. Yeah, and so I can draw like typical, like, rate limit better, like what's.

Teflon Possum: Sorry, what's this? I'll read this, okay. RL is, what is RL?

Winged Shadow: Rate limiter.

Teflon Possum: Oh, I see. Okay.

Winged Shadow: Yeah, some like our dose protection, like, it's usually placed between load balancers and APs. Well, actually, I can put P here. Okay, can you drop the, I guess, the balance? Yeah, it depends, they might be incorporated into load balancer, it might be like in front of load balancer. Okay. Yeah, it might be like even after load balancer. Yeah. Right.

Teflon Possum: Can you drop the connection between them, like who talked to who? Yeah.

Winged Shadow: Okay, give them the blue, I will put like request buttons. Mm-. Which was very he. We learn about this stuff. what I'm forgetting here. Yeah. It'S kind of like all this. Let me put it here. Have some DNS controller, something that controls our glorious DNS. Okay, and in red I output red is control. Gnosis basically controls this connection where it goes. Yeah, also typically it's somewhat like. Yeah. Some like DB controller, some like garbage collection, entropy, clean up, whatever, that there's no kind of API some like DB maintenance, DB backup, whatever.

Teflon Possum: So can you go through the flow of uploading a video? So I see that there's like, but you know, how does it actually work to upload video?

Winged Shadow: The sequence how we upload... I forgot the important part between LB and API server we need Okay. Authentication.

Teflon Possum: Yeah, you still have to first log in. So we can. Yeah. Yeah.

Winged Shadow: And in web pages, back to web pages, from login page we can go to login page. Yeah. Or it might be integrated into the login page, just like separate functionality. Yeah. So how it works?

Teflon Possum: More raw like, the user is gonna upload like a raw video, right? But there's other things that happens after that. Or are you saying that it's just gonna upload the raw video and then that's the end of uploading?

Winged Shadow: Let me think about it. I didn't get to upload what happens after upload. So we have videos. Videos, they have ID, title, some description, this can search for titles. Video has like the main like mp4 whatever video file. Video has thumbnail as we discussed. Thumbnail we also need to store somewhere. Yeah? So. When do you User upload. Go ahead. Yeah.

Teflon Possum: So when user uploads a video, it's going to be put into different format, right? So you can select different resolutions. You know, how does that work? Yeah.

Winged Shadow: You got me here. That's absolutely right. Users, they can upload videos. but in probably, that's like I was supported question in different formats. It's like for example.

Teflon Possum: So they will only upload one file, but when people watch it, they can watch it in different resolutions. How does that work?

Winged Shadow: Yeah, yeah, that's the feature that we didn't discuss it. When people watch like how YouTube works, they watch it on different resolution. They have like different bandwidth. And. Depending on their bandwidth YouTube picks. The. Video compressed into like different stuff. Yeah, so after we upload the video, they, for example, they upload some MP4 file.

Teflon Possum: Okay.

Winged Shadow: What we want to do with the video, we want to convert it into multiple resolutions. for different boundaries. And. It'S actually not resolution because we use MPEG-4, it's pretty much scalable. You don't have pixels, you have zones that scale by itself. But they have compression ratio. And also, you want to cut video into chunks because one API server streams the content back to the user. It doesn't go to blob storage and serve give me like entire gigabyte of the video. It doesn't need this gigabyte of the video. The user will spend an hour to get to the end of the gigabyte. So we cut it into small chunks and the peer server will get a chunk after chunk for usually for a minute or a couple of minutes ahead of playback.

Teflon Possum: Sure.

Winged Shadow: Let's get back to that.

Teflon Possum: So let's not worry about streaming the video yet, just on the upload path. So what's going to happen? So when you click upload, is it gonna...

Winged Shadow: It requires a new component that is not here yet. And components would be... you hear?

Teflon Possum: Okay.

Winged Shadow: We just call it processor. Okay. Yeah. And for the processor, Also have some like scales. Yeah, you have like multiple processes. And you will have some queue. And let's choose like draw some lines. Like, You put what API server does on post. It gets the blob from the client and it puts this raw original first blob into blob storage. and it puts this blob into the ID of the video in the queue. And the processor will pick it from the queue, with multiple processors, will pick something from the queue and process it and put recompressed video back into the queue. Blob storage and, like, back to our database for users. We need all IDs, original Blob ID, like different compressed file, AGs, and we also need processing status. What's going on with this video? Is it like uploaded, it's processed, like what compression is available and so. like processing status, we can dive into details. We don't have to go into details. Because we are running out of time.

Teflon Possum: I have some other questions.

Winged Shadow: So let's look at the-- yeah, just a little bit about upload. Do you bonds that you resume upload?

Teflon Possum: Sorry, what's the last sentence?

Winged Shadow: Resume uploads. If they, for example, start uploading video and video like gigabytes, and they spread like 40 million support in it, and suddenly something happens and the internet goes down and they upload interim. You probably want some functionality to resume upload.

Teflon Possum: Right, I understand that, but let's not focus on that, because we have other parts to go to. So let's go to the second requirement, which is the user can stream video. So how exactly does streaming work? So I see the flow for uploading. How about streaming? Can we draw out how that works? Is the client directly reading the video? Yeah.

Winged Shadow: How streaming works. clients, our JavaScript connects to a cloud bouncer to API server with a request to start video. API server upgrades HTTP connection to WebSocket. And they need to have indication about the initial resolution. And API server looks up in the VideoDB, looks corresponding blobs and starts to see them client video chunk by chunk. And at the same time, clients feed the API server with information about rates and desired resolution. The goal to switch resolution during playback.

Teflon Possum: Sure, but like where is client reading the, you know, the data from? Is it client reading directly from the Blob Storage? Because right now, you know, the data only exists in Blob Storage.

Winged Shadow: The client establishes web socket through load balancer with the API server. Or we can actually discuss it like API server doesn't have WebSocket support. It has very fast request response connection. Client has WebSocket connection to our system and it has WebSocket connection. First of all, HTTP requests that you initiate with what video you want to watch. Yeah. Sure. Then we can switch to-- I can switch to Websocket right now. And in Websocket, we should have protocol where client tells API server what box is desired resolution and where in the video the client is currently at.

Teflon Possum: I understand that part. My problem here is that if for a single video, you only have your data is only in the blob storage, then if it's a very popular video and people around the whole world-- yeah, yeah.

Winged Shadow: I know what you're talking about. Yeah. Let's explore some caching technology. Yeah. If it's like popular video and. A lot of users want to watch this video and Just assume for a moment. That the video is, for example, short enough to fit into the cache. And the cache is much faster than blob storage. Which is, by the way, it's not given. like some research that. Sometimes. Especially if the video is big and user like watch it from like different size. Yeah, yeah. So I would say that cache for the popular video require some numeric research. If it's justified or not justified. Usually, like intuitively, we want to put cache for popular videos and speed up and reduce loads. But you really need to get into numbers and latency between cache and how the videos support in the cache, because videos might be big.

Teflon Possum: Cache can help. Is there any other thing that can help?

Winged Shadow: If it's a popular video, what other things can help? Well. Can, because our blob storage is distributed usually. You don't want all our thousands of API servers go to the same shard in the blob storage to get this particular video from there. It means that for very popular videos, for all our thousand CPR servers trying to get it, you might duplicate this video into different shards so they don't go into one single chunk.

Teflon Possum: I agree. Do you know what is a CDN?

Winged Shadow: CDN? Yes, CDN. Can we get the context distribution network? Yeah, it's just a system of global system of many, many file servers that host content. and instead of going to like load balancers and like API servers, they can just download static stuff from CDN. And usually there's like DNS and there's like some like special DNS that's not like pay into account, closure between clients and particular CDN servers. Yeah, so we can use CDN here, but with some considerations. And some, like number one consideration, if we do CDN, then like they make it easier for the users to download the video. If it's a concern then maybe like static content in the web, it's like something like that is downloadable without authentication might be not the best solution. If it's not a concern, that's yes.

Teflon Possum: VM can also store video.

Winged Shadow: In this case, if you want to use CDN, then our protocol will change. The client goes to API server and instead of really getting chunks of video from API server, they exchange change. Information. About client wants to watch video with this resolution starting from this second. And the GI server replies with the CDM URL or ID where to get this job. Or better replies with the array of IDs for like next and next chunk and next chunks of clients for most businesses.

Teflon Possum: Okay, so yeah, I think we can stop here. So we have like about six minutes left. I want to just share some feedback. So I think overall it seems like you have enough understanding of different things. But I think one thing is, I think CDN is, let me change my input type. so I'm just gonna make some notes down here. So I think, you know, CDN is definitely a very important part of, you know, in general YouTube design or like, you know, Netflix, any kind of like video streaming service. Do you have to use CDN? I don't know if there's like any popular, you know, video streaming service that doesn't use CDN. And CDN is usually used together with, you know, Geo, why is this so hard to type geo DNS routing? So basically, the DNS server is gonna try to route you to the closest CDN server so you can, so it's like closest to you, so the latency is like minimum. And one thing that we didn't have a chance to get into because we're running out of time, basically, you know, For the database you choose, we should talk about MySQL, I mean SQL, not MySQL SQL versus NoSQL in general. So I think when you get to the database part, you could quickly address that, oh, this is going to be a SQL or a NoSQL database and why. So that's one thing. Yeah. Yeah.

Winged Shadow: It doesn't even get you exact API some database schema.

Teflon Possum: Yeah, right. And you know the API, so like the API REST API, right, for example. Sign, so I think we're just like, how do I say this? I think overall the pace is like a bit slow and I was trying to, I think one point is like I often have to like interrupt you, you know, in order to steer the direction of the interview because I think a lot of time you are focusing on things that's actually not the focus of this interview. For example, like rate limiter, rate limiting, and then you were asking like detail about, oh, what are all the constraints on uploading the videos, right? And I think these are all good things to get to, but if I say things like, yeah, this is not that important, we don't need to know the details, that kind of stuff, then that means the interviewer actually doesn't want to know about those stuff. So we can quickly just steer toward the next question basically in this case.

Winged Shadow: Okay. Yeah. And.

Teflon Possum: Then also like, I think. You. Know, I think you spend some time on capacity planning, right? So if you really want to do capacity planning, you should definitely write down the numbers. Because I think you asked like some question around capacity planning, then you didn't really give any like estimation at the end. So, you know, that time is kind of like wasted. Because you spend time on trying to ask clarification around estimation, but you have like no conclusion out of, you know, that 10 minutes you spent, right? And I would say out of like, so I've also interviewed outside a lot and from my own observation, capacity planning is usually not that important. Like a lot of the interviewers, like when I interview for other companies, senior role, they don't ask about capacity planning at all. So I think capacity planning is something that you should only talk about if the interviewer specifically asks for. I think I found like, I don't know, maybe like 30% assistant design for all the different companies. There's only one interviewer that asked me to do capacity planning in detail. And others, I just spent one or two minutes on that and I still passed the interview. So capacity planning only when asked. Yeah, so that's one thing. And then the other thing is, let me see. Yeah, so we actually didn't get to the, I guess, like the search search for video part. And I mean, that part is actually very simple. I was just trying to, you know, ask the candidate. So I just want to make sure they can know to use Elastic Search and that's what I want to get out of it.

Winged Shadow: Yeah, yeah. Yeah, that's I got from my interview preparation. On the question on search, you just answer Elastic Search on Google.

Teflon Possum: Yeah, yeah, yeah.

Winged Shadow: Right.

Teflon Possum: And let's see. And yeah, so I was also going to have a follow-up question, which is how do we store the progress of videos a user has watched? So video progress, it's like a small ball question. And the solution is also pretty simple. You just have kind of a history table for, and then the key is just the user ID, video ID, and then the video offset. and then you can just update the video offset periodically as the user keeps watching the video.

Winged Shadow: Yeah, yeah, yeah. Probably the more important function would be to resume watching video after user log out and log in again. Yeah.

Teflon Possum: And then one more thing is, I think, We mentioned about like streaming, so basically streaming over HTTP and then I think there's like these two protocols that you should, I mean it will be great if you can mention them. So one is stash, which is dynamic adaptive streaming over HTTP. The other is like HLS, which is HTTP live streaming. So HLS is used by Apple and then, you know, stash is used by the rest of the world. and it will be great if you can mention them. You know, it's fine if you don't, right? Because like not everyone is like very familiar with them, but I think if you mention them, that's like a plus. And then one more thing is like a transcoder. So transcoder is the thing that and transcode the original format to all the different output format. And it's basically like, you know, the processor part that you write here. And, you know, calling them processor is fine, right? But, you know, It's even better if you know that they are transcoded. Let me see, is there anything I can cover? Yeah, so I think that's the major thing. I think overall just like the pace should be faster and maybe try to push towards covering all the basic stuff. You have to cover, what you have to cover, you have to have the overall system diagram which you have here, the data model, which you have it, but you didn't mention the SQL versus no SQL, and it's not super complete either. And then you have to cover the REST API. So what are the list of REST API? They're all just like, what's the input, what's the output? And then for capacity planning, I would suggest only do it if the interviewer specifically asks you to do it. Because from my experience, interviewers usually don't care about capacity planning that much.

Winged Shadow: Great, thank you so much.

Teflon Possum: Okay, yeah, so do you have any questions?

Winged Shadow: No, I just want to hear your feedback, like if you're interviewing me that's what you expect, what I am missing, what I'm doing wrong, yeah, and feedback is great.

Teflon Possum: Okay, cool, great. So yeah, so if nothing I think we can end the interview here. Thank you. Have a great night.

Winged Shadow: Thank you so much.