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

Design a Dating Application

Watch someone solve the the problem: design a dating application (medium) problem in an interview with a FAANG engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.

Interview Summary

Problem type

The Problem: Design a Dating Application (Medium)

Interview question

Design an architecture for a dating application where users can log in and see other nearby users. The system needs to handle user authentication, profile management, location-based queries, and scale to support 1 million daily active users. Key considerations include database schema design, API endpoint structure, and performance optimization strategies.

Interview Feedback

Feedback about Green Stingray (the interviewee)

Advance this person to the next round?

How were their technical skills?

3/4

How was their problem solving ability?

2/4

What about their communication ability?

4/4

Strengths: * Good breadth of knowledge of backend components * Understanding of various issues a system could face Areas for improvement: * Designing quicker to be able to cover more ground during the interview * Avoid diving into corner cases too much initially * Keep things simple, at least at first, and add complexity as needed Advice: * Have default technologies you use for things unless the problem requires otherwise Keep up the good work!

Feedback about General Centurion (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?

3/4

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

4/4

The interview was a fantastic experience, I appreciated the feedback segment at the end. I don't really have any constructive criticism, maybe I felt a lack of direction in some parts of the interview but I suppose the intention was to see which direction I naturally headed towards.

Interview Transcript

Green Stingray: Hello!

General Centurion: Oh, hello! Hi, how are you doing? Good, good.

Green Stingray: How about you?

General Centurion: I'm doing great, thanks for asking.

Green Stingray: Awesome, awesome. Well, okay, we've got about an hour. Let's see, just— I think we spend like about a minute each on intros, just give some background info, and then the vast majority of the time— that'll help me. I'm also understanding decide how to kind of give the interview. And let's have you start and kind of tell me a bit about what you're looking for from the interview.

General Centurion: Mm-hmm. Yeah. Awesome. So I'm applying for a front-end role. I'm looking for— I, I just got past the screening phase, so now I have my onsite. It's gonna be scheduled maybe in about 1 or 2 weeks. I've not done a system design interview before. So this is new territory for me. I just read a book, a system design interview book by Alex Xu. I'm just looking for pretty much anything at this point would be very helpful, I think, just an experience of what these interviews are supposed to be kind of like, what to expect from it, and then what to expect when I go into the real interview, you know.

Green Stingray: That makes sense. Okay. Interesting that they're having you do a system design with a frontend role. Okay.

General Centurion: Hey, yeah. Yeah.

Green Stingray: That, that's tricky. Okay. Um, so from my background, let's see, I've been at a bunch of different tech companies. I've been at [REDACTED], um, a crypto startup, uh, [REDACTED] and [REDACTED]. Um, so kind of been all over the place. Um, and mostly been backend focused, um, but done full stack work as well at various places.

General Centurion: Mm-hmm.

Green Stingray: Um, as needed. Um, okay. So let's see. So best thing, what areas are you most familiar with? Like as, as far as Backend systems?

General Centurion: What kind of— So I'm working on, I'm almost finished, I'm almost going in for the [REDACTED] exam, so everything covered there pretty much. So I guess like load balancers, having multiple instances, edge locations, content distribution network.

Green Stingray: Okay, okay, okay, cool. So the building blocks you're familiar with a bit. Okay, let's try this one since, um, mm, okay, I'll just try this and see and then we can iterate. So the basic idea here is, so, design an architecting dating application where users can log in and see other nearby users.

General Centurion: Awesome. Okay, so let me think about this for a second. So I can, I can just type here, right?

Green Stingray: Okay, so— and there's also a whiteboard in the bottom left we can toggle.

General Centurion: Oh, awesome. Okay, that's even better. Let me just read that again. Um, okay. So, yep, looks good. Okay, let me think about this for a second. The way I like to see this, the way I like to start off, is I like to look through all the keywords in here.

Green Stingray: That makes sense.

General Centurion: Yeah, so dating application, users can log in and see nearby users So there's going to be a couple of requirements here right off the bat. One is going to be for the dating application. Let me write this down. We're going to need some kind of matching algorithm, perhaps.

Green Stingray: Mm-hmm.

General Centurion: For the login system, we're going to need authentication, maybe authentication Yeah, obviously some authorization as well.

Green Stingray: Are you typing this where I can see it? Might as well type it in the main.txt.

General Centurion: In this main— Oh, instead of doing it on the whiteboard?

Green Stingray: Oh, oh, sorry.

General Centurion: Oh, I just—

Green Stingray: oh, this is great. Oh, yeah. Love it. OK, yes.

General Centurion: OK, thanks. OK.

Green Stingray: Awesome.

General Centurion: And then the nearby users, so we're going to have to have some kind of geo proximity. Location microservice of some sort.

Green Stingray: Yeah, oh, got that. Yep, yep, yep.

General Centurion: Okay, um, now that we've got the starting point, let's think a little harder. Let's think on the matching.

Green Stingray: Um, I'd say go simple. And instead of matching, we could also imagine— like, that sounds— that could be quite complicated. So initially, let's imagine just having some sort of like user profiles.

General Centurion: Okay, cool, cool. So matching algorithm, just not really. We don't really have to get into the algorithm.

Green Stingray: That's— we could, we could, but that— let's, let's save that for one of the last things if we have the time.

General Centurion: Cool. Um, some other things to think about. Let me just, let me just almost like brainstorm, just write things down. Um, maybe traffic handling. What are the limitations of this, or what are the minimum requirements? How many users are we going to be getting?

Green Stingray: Um, what would you think?

General Centurion: Probably, um, say for a very popular one, you could have like millions of users on a per-week basis for something like Tinder or something.

Green Stingray: Yeah, let's say we're not that big, but let's say we want to handle at least like, um, like, uh, let's say 1 million active, 1 million daily active users.

General Centurion: Okay, that's quite a lot. Um, Okay, so traffic. So traffic is going to be something we definitely have to consider. Probably going to have to split up the backend a bit. Maybe some load balancers and whatnot. We got to think about database. How to database sharding. Stuff like this. What else? And then on the more of the frontend side, we're going to have to have some kind of content distribution network to provide all these static stuff like, you know, images and whatnot.

Green Stingray: That's a good point. Yeah, you want to put those in the CDN.

General Centurion: Yeah. Okay. So use a CDN to provide static images. Awesome. Let me think about this for a sec. So maybe we can start drawing a little. Mm-hmm. Basic, almost like a diagram kind of. So, we can have users.

Green Stingray: Oh, instead of doing that, there is— if you in the top right, you see on the— there's a toolbar on top. And then, there's a little icon thing in the top right. Oh, no, no, no. It's not that. Click the library in the top right.

General Centurion: That thing.

Green Stingray: And then, do you see browse libraries? Yeah, then click Browse and then type in System Design.

General Centurion: I see.

Green Stingray: If you type it, yeah, then there's System Design Components. It's nice and you can say Add to Excalidraw if it's not in here. It might already be in here. Okay. Do you see all the System Design stuff?

General Centurion: Let me just add these then. Do I see them? I don't see something that says System Design.

Green Stingray: Okay, yeah, you'll add it specifically. It's in the list.

General Centurion: Cool, cool, cool.

Green Stingray: And then you'll have all these nice convenient ones.

General Centurion: Mm-hmm.

Green Stingray: Like this mobile thing to like show the user.

General Centurion: Oh, is it just these like little icons, I guess?

Green Stingray: Yeah, it's just all these icons, yeah, that are kind of— Okay, okay, okay. And then it just, it saves time and it's very repeatable.

General Centurion: Sure, sure, sure, sure. Okay, so we're gonna need this. DocumentDB, we could, we could use a DocumentDB for this platform as well. Um, because if we want more simple data, cold storage, uh, getting a little into the weeds here, I think. But maybe I'll keep it here in the corner. It's just hard to see, uh, without actually clicking the thing and making it show up what it is. I'm kind of just clicking and then seeing Do I need this? Um, cloud. Sure, this could be like in the middle. Let me position these a little bit. Um, so mobile is gonna be the client side. Relational DB could be like somewhere over here. Auth and IAM. Content distribution network.

Green Stingray: Cool, makes sense.

General Centurion: Um, I'll draw a bunch of arrows momentarily. For now I'm just doing the basic. Okay, could be like mobile.

Green Stingray: Maybe web app. Yeah, mobile and web, very common.

General Centurion: Yep. Okay. Question is, do we need a document DB or an object DB? I'm thinking, can we just get away with using a CDN and a relational DB?

Green Stingray: What's the trade-off of relational versus document?

General Centurion: Relational is more rigid. Document is a little more flexible. Document is arguably more scalable, but it's not as flexible. For something with a lot of like social, social connections, something like Facebook, you'd want something a little flexible. You don't necessarily want something rigid, but I think you could also kind of use a combination of both.

Green Stingray: Usually the number one thing in my opinion is relational favors writes. Generally relational DBs are, they're more flexible as you're saying, but they're also, they perform well when there's more writes than reads often.

General Centurion: Okay, that is true.

Green Stingray: They, yeah, you'll definitely with a denormalized model, Uh, and then whereas a document, usually you do a highly, um, norm— no, he's like, with document you go normalized, with relational you go denormalized. And when you go, um, and yeah, document, usually you make it so it's usually biased towards this design where it's more read-heavy. So, okay, with this kind of a thing, do you think there's more writes or reads coming through?

General Centurion: More reads. Definitely more reads. Okay, um, okay, that's a good point. I guess we can stick with a document DB, but maybe relational DB.

Green Stingray: Um, I think in this case a relational DB would be fine still, actually, though. But, um, so I think it really doesn't matter, to be honest, in my opinion.

General Centurion: Okay, sure, that's fine. Uh, what else do we have? These are all like DB options. I'm just looking at all these pictures.

Green Stingray: You definitely want to bring in like an application thing, right? For your API server. Um, and this one, there's two ones, right? Um, like you have this one which is just a basic server. You almost never really want to use that one because you'd want the multi-instance server.

General Centurion: Mm.

Green Stingray: And this is showing you that you have multiple copies of something, right?

General Centurion: Um, right, right, right, right, right, right. Okay, that makes sense. Uh, okay, so here's what we're going to do. We can have How do I delete this?

Green Stingray: Yeah, just click once on it and then you can edit the text by— how do you edit the text?

General Centurion: You'll just leave it for now. The message here is going to be very important. I'll get into that.

Green Stingray: A in the top. A in the top.

General Centurion: Okay.

Green Stingray: A, A, A, A, and then Yep, I see.

General Centurion: Oh God, what have I pressed? Just one sec. Oh, there, there we go. Cool. Found it. Okay. Message queue is going to be very important as well. I'll get into that in a sec.

Green Stingray: Pretty helpful. Yeah.

General Centurion: Okay. So the server, we could have like some kind of split, like cloud and on-premise, or like outsource some, some of the microservices to the cloud. Something like CloudFront for CDN is like really convenient, or Cloudflare. So I'm going to leave cloud in here. Okay. The servers. Maybe we'd want something, we'd want to manage our own servers. We could, let's leave this multi-instance server right here. Cold storage, we can kind of leave that. Cold storage could be, let me think about this for a sec. For cold storage, we could have like static, static stuff that could be kind of in line with the content distribution network. So you could outsource that to the cloud as well, maybe use like, you know, like S3 Glacier or something on Amazon for the cold storage. What would we store in there though? Maybe like old, like inactive users, we could store all their info on there. I think that's going to be more important for media, less important for like text values, like their name and whatnot. It's not going to take up too much space, but I think cold storage also can be your can be related to a data warehouse. Okay. Yeah, sure.

Green Stingray: If you're trying to like, uh, yeah, but that, that we don't need to worry about that.

General Centurion: Cool. Um, what else? Okay, so the message queue. Let's think about this for a second. Message queues are really good for decoupling. Um, we're definitely going to want to have some message queue kind of be that middleware that connects the client side to our backend in a lot of cases. Um, let me think for a sec. Let me think of a practical example in a dating app. Let's say, what's something that might be like a little bit asynchronous? Let me think for a sec. Maybe you match with someone, maybe—

Green Stingray: I don't know if the current requirements need one yet, to be honest. Everything you've said so far doesn't need it yet.

General Centurion: Maybe not, maybe not. Yeah, okay.

Green Stingray: I mean, I can get something in later with like notifications, right? Um, like, uh, when, when you match with someone setting. But let's— I'd say let's not shoehorn the technology in yet. Let's get— let's hook these up with, um—

General Centurion: okay, sure.

Green Stingray: Um, and then As we expand the requirements, add more technology in.

General Centurion: Sure, sure, sure, sure. Okay, so let's think about auth for a second here. Auth is gonna be— we wanna— where do we wanna put auth? Let me think about this for a sec. Is this in the right place? So, auth. Definitely going to be between the server and the client. Hmm. I feel like I'm a little all over the place now. Do you have any kind of sort of a direction for me to go next with this plan that I have?

Green Stingray: My suggestion would be is follow an API request just coming in, right? And like, so— Right. And that's something that the user wants to— needs to do, be able to do, the capability. Okay. So, let's say that they need to like view nearby users, right?

General Centurion: Mm-hmm.

Green Stingray: And so, they'll send a request. Like, what's the first thing it hits?

General Centurion: Right, right, right. Okay. Awesome.

Green Stingray: Okay.

General Centurion: So, they're gonna send a request. HTTP request. First thing we do, I'd imagine we check if it's authorized. We could check if it's authorized once it hits the server, or we could check before. The authorization would have to be server-side, obviously. Yeah, right. Yeah, so, yeah, so you check authentication authorization.

Green Stingray: Right about— so like that, I would— yeah, I'll have you see. So like an API request would come in, right? And it would probably hit the server first, uh, and then it will do some amount of auth logic. I mean, honestly, this, this question isn't really about the auth logic, so we don't need to worry about that very closely. It could either hit some service or, you know, have some library, um, with the database. Not super important. Um, so we can— we could like— let's, let's leave that vague for now because it's not really critical to the system.

General Centurion: Makes sense.

Green Stingray: And that could be powered by MongoDB. Let's, uh, which one are you more familiar with, relational document database?

General Centurion: Probably document.

Green Stingray: Yes, let's go with that then. Okay, so let's say we're building on this, um, and then, okay, so request comes in, it hits this service. What's running? What, what code is the server running? Is it like, what would you use to run the API server?

General Centurion: Oh, um, You could have some kind of backend. You could have Express or something.

Green Stingray: Okay. Yeah. So, I'd do it, yeah, it's an Express API server. Sure. Okay. And then why is Express nice? Why is Node a good API server?

General Centurion: It's pretty— it's pretty modern. It's pretty scalable.

Green Stingray: Yeah. Scalable. Exactly. The main thing is It doesn't require a thread or process per incoming API request.

General Centurion: Exactly, yeah.

Green Stingray: It multi— it pops them onto a queue instead, whereas Java and a lot of the traditional ones, you have to really have a lot of number of threads and processes and it gets really memory heavy. Yeah. And so yeah, you can handle a lot of inbound requests simultaneously. So it's especially good for a very outer server.

General Centurion: Exactly.

Green Stingray: The— for like a first inbound. Okay. So, let's say you have this. Okay. And then this server, now what does it do? So, it's supposed to— this is like supposed— let's say they've already authenticated everything and now we're trying to list nearby users.

General Centurion: Yeah. So, then next time we're gonna do— let me check if there's something for this. It's gonna pass through a load balancer basically is what I'm thinking. Because I'd imagine there's gonna be a lot of It's going to be a lot of requests.

Green Stingray: There's always a load balancer on everything.

General Centurion: Um, sure.

Green Stingray: Okay, let's say there's like an implicit load balancer right in this arrow here, and we could like— we could even put like, uh, like a little thing. I— in the end, like, there's load balancers all over the place, and so I feel like you just kind of have to say, okay, okay, yeah, yeah, sure. But like, let's say there's a load balancer right here. Um, yep, cool, because there's multiple— there's multiple of these, so there's some— somehow has to be a way to Um, okay, uh, but then do we need another load balancer? Is that enough? Because let's say we're running like, you know, how many, how many copies of this server do you think we need to run to be able to handle a million daily active users?

General Centurion: Right, uh, back of the envelope estimation, probably say I, I'm not too sure. It really depends on, it depends on how much traffic, it depends on how much bandwidth we need.

Green Stingray: Uh, yeah, it depends on how the code's written. How good it is. Probably on the order of like 40 to 200 would be my guess based on my experience. Not that many, but a good number. This load balancer could route across all of them. Then we have all these 100 or so of these Express API servers. These can have any code in them because it's our custom Node JavaScript.

General Centurion: Yep. Exactly. Okay. Yeah. So, next thing is gonna— is it gonna hit one of our API endpoints in that Express server? That endpoint— or, well, we're just gonna authorize. Just gonna authorize authentication. Yep. Cool. And then—

Green Stingray: I—

General Centurion: so, just return what data it's looking for. If it passes all the tests, if it passes the authentication and whatever logic we have in that endpoint. So, we could have in that Node function, you could have multiple things like, oh, maybe not just that, but maybe, maybe not just authentication, but I don't know, something with their location, whatnot. But it could kind of pass through all that logic and then return, return whatever data I need. So like, let's say, let's think about this for a sec. It hits the endpoint. Let's take an example. Let's do like a dry run. So I want to look at my profile. I go to the top right of the screen. I click my profile. What it's going to do is going to go to the backend. It's going to go to a server. It's going to authenticate. See, am I, am I authorized to look at this page? It's going to say yes. So, then it's gonna call something else or like go somewhere else to retrieve this data. So, it's probably gonna— the arrows. Oh, they're up top. Oh, sorry?

Green Stingray: The arrows are up top on the bar.

General Centurion: Oh, yeah. Is that okay? I don't know.

Green Stingray: Okay. So— What is this error meaning?

General Centurion: It means that if I want to grab information from my profile, if I want to take a look at my profile, the server is going to have to— actually, wait. The content distribution network is more so on the frontend side of things, I think.

Green Stingray: Yeah, it does connect to the backend a little bit, but not directly. Um, actually, yeah, the backend would only make sure when someone is more— that's when you're updating a profile, right?

General Centurion: Exactly.

Green Stingray: We could walk— maybe it's simpler to walk through the create a profile first.

General Centurion: Sure.

Green Stingray: Okay, so let's actually— one thing you can do with this too is also kind of describe some flows. So we could talk about like create a profile, right? Um, so what would this— what would the endpoint look like for this create a profile?

General Centurion: It's Flow. Right, okay.

Green Stingray: What API call would they call and then what would happen? Right.

General Centurion: So let me just—

Green Stingray: And you can just like bullet out the, um, or like 1, 2, 3, 4, 5, like the sequence of events that happen.

General Centurion: Sure. So create a profile, um, I don't know what happened to the word profile. I'm gonna—

Green Stingray: I don't know. Make sure you're on the edit text mode and then, um, okay.

General Centurion: Um, So we get to the endpoint. It wants to create a profile. First thing is going to do the authentication. See, actually, maybe not authentication, but maybe rate limiting is more important in this case. We don't care so much whether you have permission to create a profile. We care whether you're like a bot that's like—

Green Stingray: that's a big one. Yeah, that is a highly important endpoint. Yeah, that's a good point. I like that. Yeah.

General Centurion: Yeah. So, we're gonna say like one rate limit.

Green Stingray: I don't see your text typing for some reason.

General Centurion: I— it's a little bit lower down.

Green Stingray: Is it all in white?

General Centurion: No.

Green Stingray: No. Really? Let me— I'll leave the whiteboard and come back to it.

General Centurion: Hmm. Weird.

Green Stingray: Okay.

General Centurion: But yeah, I mean, I just wrote one rate limit. That's the first thing. If you want to create a profile. Go ahead. Let me visualize this for a second. Create a profile. We want our rate limit. What other requirements can we do? Can we just— we're going to handle some kind of form basically. We're going to validate this form, validate the data. That could be all on the frontend.

Green Stingray: Yeah.

General Centurion: Yeah, so the frontend is going to validate this data, send this data to our endpoint, the endpoint is going to do all the rate limiting. And then once we hit submit, or well, once you submit, it goes to the backend, checks the rate limit. Oh, and then it's going to check if we— that user already exists. So it's going to have to make some kind of call to the database. Um, maybe match, search, search for like a certain name, I guess. What would it match in this case?

Green Stingray: Let's, um, put over here, we can put your, uh, model for like what the— how you want to use it. Um, like what would you call the document collection, right? Um, like what collection do you do and what fields would you put in it?

General Centurion: Yeah, okay. So let's say user. Let's make this a little bigger. Can you see this text, by the way?

Green Stingray: No, that one also is not visible. Let me quickly refresh this thing.

General Centurion: Oh, maybe.

Green Stingray: Yeah, yeah, I'm back. Let's see. No, I still don't see your new one.

General Centurion: This is so weird.

Green Stingray: Never had this happen before. But you see my create a profile, right?

General Centurion: I see that, yeah. I see that.

Green Stingray: And do you see this if I type in database?

General Centurion: Yeah, I see that.

Green Stingray: And then try editing that one. Does it— do you see?

General Centurion: Let me see. Yeah, I can edit that, yeah.

Green Stingray: And then save it. You should— maybe you should refresh yours. Yours isn't— your changes aren't getting uploaded to me, I think.

General Centurion: Oh, you want me to refresh? Yeah, try. Sure, okay.

Green Stingray: It'll cut off for a second and then—

General Centurion: Okay.

Green Stingray: Oh yeah, yeah, it had a warning thing, not connected to call before, and now that went away, so I think—

General Centurion: Oh, I see, I see. Oh yeah, oh, that's weird. It like wiped what I wrote. That's fine. OK, you can see that though, right? What I'm writing now?

Green Stingray: No. Are you done typing it? I just typed it. I see you moving around though.

General Centurion: I think try adding something. Oh yeah, let me see. No?

Green Stingray: No.

General Centurion: Hmm.

Green Stingray: Where did you add it?

General Centurion: Right below document.db. Really?

Green Stingray: Yeah. This is unfortunate.

General Centurion: We can—

Green Stingray: but the arrows, do you see— when you add arrows, do I see those? Um, I—

General Centurion: yeah, like if I add an arrow, can you see that?

Green Stingray: Also no. Oh my gosh, this whole thing's buggy. Okay, well, let's not worry about the diagramming for now. Let's go over to the, um, let's toggle whiteboard and go back to text mode. Um, let's dive into some of these other things and maybe it'll work.

General Centurion: Okay, sure, sure.

Green Stingray: Here. Yeah, database. Okay, you're saying there's gonna be a users table. Yeah, they're not able to get collection if it's documents, right?

General Centurion: Um, yep, collection. Okay, so users, uh, in this case, okay, I'm thinking a little SQL here, but oh, that's fine. Yeah, I, I mean, I, I guess like with the document store you don't really have like a schema because it's just flexible, but you still need to— you still kind—

Green Stingray: I mean, you don't technically have a schema, but in the end your application needs your schema. Yeah, you're Yeah, okay, yeah, random objects in right now.

General Centurion: Same code, yeah, same code runs on same people, so it's gonna be pretty much a schema. Okay, so we're gonna have ID, this could be like UUID or something. Um, yeah, it doesn't matter too much what format you use, I guess, but UUID is pretty Pretty efficient.

Green Stingray: Yeah.

General Centurion: UID, this could be like the primary key. Uh-huh. Again, not really a document store thing, but for the sake of system design, we're gonna say we need a primary key and that's gonna be the ID.

Green Stingray: Okay.

General Centurion: And then we're gonna have name, could just be text. Name. Yeah, we could have like first name, last name, and whatnot. Mm-hmm.

Green Stingray: That makes sense. A little more structured. Yeah.

General Centurion: Yep. First name, last name. I mean, we could, you could do so many, you could do so many of these. You could say age, basically everything the user fills out in the form. So like email.

Green Stingray: Let's say there's also like a list of tags that they can pick from that there's like like 20, like 30 tags that like, like hiking and like that kind of thing. Right. Okay. So I think, okay.

General Centurion: That makes sense. Yeah.

Green Stingray: The text array. Okay.

General Centurion: Yep.

Green Stingray: That works.

General Centurion: Yep. Yep. Cool. Cool. Cool.

Green Stingray: And then let's also say there's gonna be photos that they upload. Let's not worry about the details about how they upload 'em, but let's just say there's a list of photos that they wanna—

General Centurion: Right. Okay. The photos could also be, uh, links, an array of links that refers to CDN. Nice.

Green Stingray: Okay, yep, yep, yep, totally. That's a great way to do it. Okay. Anything else that's interesting on the user side, let's think.

General Centurion: Yeah, I'm trying to think. Anything on the authentication side we ought to store?

Green Stingray: On the requirement side, we want to show users that are nearby, right? So we might use— True.

General Centurion: True, okay. So something about their location. I saw— okay, I heard of this algorithm Uber uses for their geolocation routing, which is they split up the map into these like hexagons. Oh yeah, it's inside a hexagon. Um, so maybe every hexagon could have some kind of ID in this case. Yeah, maybe that could be like a separate —separate stuff.

Green Stingray: That gets really complicated if you have Spark. Yeah, okay, sure.

General Centurion: Keep it simple.

Green Stingray: I'd say the requirements doesn't say it has to be accurately near, but like, you know, it just says nearby. So, okay, yeah, sure, let's just say city. No, no, that— yeah, I mean, that's a whole— that's another approach to this problem that's very interesting. Yeah, sure, but I would not expect someone to do that. Okay, so yeah, okay, a freeform text city. And then if no one else is online in that city, what would you do? Or like if there's no other users in that city? Oh, okay.

General Centurion: I see. Um, no other users in that city.

Green Stingray: I guess I think it's perfectly fine as one of— I mean, it's, you could just say that you'll say that there's no people there and come back later or something, I guess. Right.

General Centurion: That would be one option for sure. Yeah. Oh, you— okay. So. You mean if the city is like invalid almost?

Green Stingray: No, but like if the first user and it's a small city, like a suburb of a nearby city.

General Centurion: Oh, so you'd create it, um, you almost like create the city in our DB?

Green Stingray: Yes, essentially.

General Centurion: Yeah, yeah, yeah. I think that could just work with the document store.

Green Stingray: Yeah, if the city does not exist, I would just create it. Okay, okay, um, okay, it seems good. Okay, city, country Very freeform photos, tags, email. Okay. Age. Okay. Cool, cool. And then, so that create profile endpoint, right? Mm-hmm. Endpoint, create profile. And then you said it would, one, rate limit, check rate limiting. Mm-hmm. Okay. And then two, and then what else would it do?

General Centurion: Okay, so check rate limiting. Grabs data, basically. We could expand on that in a sec. Just going a little higher level first. Create profile. So, yeah, we check the rate limiting. Grabs data.

Green Stingray: How does this work, by the way?

General Centurion: How would you do that? Oh, you could go into the nitty-gritty details on that one.

Green Stingray: But, um— basic but actually functional in a way that would work. Right.

General Centurion: Um, let me think about this for a second. So, you could have some kind of like ID for every user almost, or—

Green Stingray: ah, you didn't have yet. Their pre-creation, right? Usually, yeah, yeah, yeah, yeah, most people do IP address.

General Centurion: It's typically, yeah, it's typically like network, network IP address. Yep.

Green Stingray: I think that's right. Let's imagine we take the network IP, then how do we— let's say we want to cap it to like 5 per hour per IP or something, right? Just in case there's like a few people at the same address all trying it out. How would we do that?

General Centurion: Yeah, okay, so Okay. I'm trying to remember now. I think you could have like some kind of counter basically for every— have a bunch of counters for the requests coming from every— different IP address.

Green Stingray: IP address.

General Centurion: Almost like cache it. Yeah.

Green Stingray: So— okay. So, here's— it'll get really messy if you have all— if you store it in the code, right? You'll have 100 different versions of each counter because they're all— Right.

General Centurion: We could store— like only store for about like 5 minutes, basically.

Green Stingray: In the database or in where?

General Centurion: Yeah. So, we could have like in the document store maybe? Okay. Here's— Here's another way I think I remember reading about is we could do like some kind of bucket where I don't remember exactly how it works. So we have some kind of bucket where we say like a user has a certain number of tokens to use for requests. They fill up the bucket and then once it fills up, You could— they can no longer make requests. Um, any, any more requests they make just go like out the window or ignored.

Green Stingray: I think you definitely want to do rolling of some sort because there are just IPs that are very heavily used, like from universities and things. Um, I'd say what about— what do you guys like this? Like if you just added signup IP, uh, yep. And then you also— if you know that each user's signup address, right? And you need their created timestamp. What about that? Then could you do a DB query to figure out if they should be allowed to make a new one from an IP?

General Centurion: Yeah, that's a simple way to do it. Um, I think one limitation would be like, what if— what if I guess they're doing like a DDoS attack and they have multiple IPs? This wouldn't like fully cover that risk.

Green Stingray: Oh, if someone has multiple IPs, you're kind of just screwed. Yeah. How else would it— how would— like, because that's— yeah, the— I don't know what else.

General Centurion: Yeah, I'm not sure what you can do to avoid that.

Green Stingray: Yeah, I mean, you could either do it, like, through some ML algorithm to see if the data is actually interesting. You could— like—

General Centurion: yeah, or you could have some kind of, like, centralized rate limit where— but then that's how—

Green Stingray: hmm. Oh, just to keep the server from going down kind of by it.

General Centurion: Yeah, but then that's how all the other users get blocked though then. But then everyone— yeah, exactly.

Green Stingray: I think what I've seen is you usually just do per IP rate limiting. And then you usually put Cloudflare in front as well. Or yeah, that's the one. Yeah. And then they usually handle the massive scale. Like a reverse proxy of some sort. Yeah, exactly. Yeah. Usually they become your, uh, ingress, uh, like the outer edge. Um, okay. Yeah. So that, yeah, let's not worry about the massive issue. Okay. Yep. So in this case, with the data model, which columns would you want to be indexed? So like MongoDB does actually require you to tell you if you want to be able to query on a field specifically, you do have to actually add an index on it.

General Centurion: Okay, I guess ID would make sense. You would have some kind of hashing algorithm.

Green Stingray: Yeah, yeah, that one, well, like at least with Mongo, that one will always be indexed. But yeah, you definitely want that to be. What else?

General Centurion: Um, let me think.

Green Stingray: City, maybe. I think, yeah, I think you'd want to index on that because, um, if you're trying to find other users in that city.

General Centurion: Yeah, that's going to be a very common lookup. You want city ID, it's going to be by default. Age probably is going to be a common a common lookup. Mm-hmm. What else?

Green Stingray: How it's— when someone signs up, you're going to probably want to prevent a duplicate.

General Centurion: Hmm.

Green Stingray: And what fields, how would you define that?

General Centurion: Oh, then I— yeah. Um, emails, right? Yeah. You can't have a duplicate email.

Green Stingray: Yeah. Generally that would be the kind of the thing that you dedupe on. Yep. And then what about if you're using these— if you're using signup IP as doing the rate limiting? Would that need to be indexed?

General Centurion: Um, yeah, yep, that's going to be a common one.

Green Stingray: Otherwise it'll be very slow to query on that field. Okay, okay, yeah, true. Okay, yeah, I think those are the ones that you— there's minimum needed.

General Centurion: Yeah, and then yeah, I guess you could shard by ID.

Green Stingray: So in this case, um, you actually with this volume of things, you actually don't need to shard either. Um, uh, generally like having just a million data, it's a fair number, but you don't actually need to. I mean, yes, but if you needed to, you could shard by ID. That's true. Um, okay, I'm not sure the scale of this thing would even require sharding. Yeah, yeah, once you start sharding your database, it gets pretty weird.

General Centurion: Okay, yeah, would it be fair to say it's—

Green Stingray: sorry, what are you gonna ask?

General Centurion: Would it be fair to say with the document store, I guess you don't really— with something like this, um, does the document store have something to do with it not having to—

Green Stingray: yeah, honestly, that, um, yeah, you— oh, so you only need to start worrying about sharding is once your writes are super heavy. Reads, you can scale up multiple readers.

General Centurion: Yeah. Oh, okay, that, that makes total sense.

Green Stingray: Yep. And so the signups, like, this thing isn't gonna— like, if you're having more than a, like, 1,000 to 2,000 writes per second, then you definitely want to shard your data. Like, it's like, yeah, you need to be in the thousands, like many hundreds of writes per second before you need to shard. Right, okay. Whereas this group probably have a bunch of reads per second.

General Centurion: In this case, it could maybe just have like a master a master DB that handles all the writes. Yeah, handles the writes and stuff, and then you just have, yeah, like clones of one.

Green Stingray: And then a bunch of readers that follow along. Yeah, that would— it's a very traditional setup and it works for a lot of stuff. And so only for like really heavy write-heavy stuff do you really need to worry about the other more complicated. But you're right, yes, you could shard it, and Mongo makes that pretty easy to do. And it's not the worst with the documents. Documents are better to shard than equal stuff. Awesome. But I would just say, yeah, I would say you don't really need to introduce that until write-heavy systems are at play. Mm-hmm. Yeah. Which I don't— I wouldn't imagine you get 1,000+ users signing up every second, right? So. No, yeah. Okay, cool, cool. So rate limiting, we just said we decided that could work using a DB query, right? Yep. And then grabs data, then what?

General Centurion: Okay. Yep, checks rate limiting, grabs data. Okay, let me think about the function for a sec. It's gonna check rate limiting and then we have to check if it's a duplicate. So, it could make some kind of— make an asynchronous request for the user's email. Check if it's a duplicate.

Green Stingray: Yep.

General Centurion: If not— what else do we want before we submit? Can we just say If not, just create the profile.

Green Stingray: Let me think. Yeah, yeah, or like put it—

General Centurion: yeah, create a record in the database. Yeah. Okay, yeah, sure. Sure, create a document or whatever. And then if it's a dupe, if not, create a document in the DB. If it is a dupe, return some kind of return some kind of error. We have to return like a code in the end, right? There's an Express endpoint. Yeah, so, um, return 200, created successfully. Otherwise, um, return— I don't know what the code would be. Let's just say 409. 409, okay.

Green Stingray: Conflict means you're doing something with the— it's not like Sure. Yeah, a record that can't be created. Okay, this is good. Anything else at this endpoint would do. That seems, that seems reasonable, yeah. Okay, let's see. Okay, now let's talk about the getNearbyProfile.

General Centurion: Mm-hmm, yep, sure. Okay, so getNearbyProfile. Once again, we want to check rate limiting. And then this is going to receive—

Green Stingray: Now how would that rate limiting get to work?

General Centurion: True. Okay. It's going to be a little different, I suppose. Get nearby profiles. Huh. Okay. If it's like an authenticated user and a valid user, then we don't We don't really care. Okay, actually, so in this case it's just going to be authentication because if it's an authentic— if it's an authenticated user, then we don't actually care. Yep. And this function only really applies to authenticated users anyway. Yep. Okay, so, um, authenticate, I guess, or would that be kind of like some middle middleware? Before it reaches the endpoint. I guess it would be once it hits the endpoint we authenticate. Okay, so authenticate request user. Once we authenticate, we want to get their location. Yeah, okay, so we want to get their location, make a sync request. For users. Let's just say city for now. Let's keep it simple. And then use— use microservice for— hmm. Okay. A bit of a tricky part. If we're doing city, an intuitive way would be we grab the city, then we make a request to the DB to grab all users in that city. Yeah. Who match, who match like maybe certain other filter requirements like, oh, age, gender and whatnot.

Green Stingray: For now, let's just say that it just returns them in general. Sure. Yeah, we could like, yeah, either we could add some like, yeah, the base filters that they have an age range and things like that. Yeah, um, yeah, so we could— yeah, that makes sense. Yeah, there's some base filtering.

General Centurion: Okay, sure. Okay, I'm just not sure how efficient it is on a document store. From my experience, it's harder to make those queries.

Green Stingray: Well, the city, if the city's indexed, as long as the city's not super big, it doesn't matter. Okay, cool. So, uh, yeah, because like you can imagine that the city narrowed down to like 20,000 or something And then it's perfectly fine for the documents to filter to others manually. Yep.

General Centurion: Okay, cool. Make another request to retrieve all user documents from, from that city.

Green Stingray: And then matching with the other filters as well, right? Um, with— yeah, okay, right.

General Centurion: Okay, so in that case, so the other request Yeah, okay, so the other request would have multiple fields basically.

Green Stingray: Yeah, and, and at least Mongo at least had like a query planner. So this is where Mongo is more powerful. But yeah, what, like, I guess what DocumentDB would you imagine that you'd use?

General Centurion: Cool, okay. So yeah, make another request with all filters to retrieve all documents from user documents from the city who match the filter. Once we have all those users, is it— it's kind of— I feel like it's kind of a lot of data to return from that endpoint. So how much—

Green Stingray: yeah, would you cap the results? How many would you cap it to? Right, exactly.

General Centurion: Okay, um, you'd cap it to— I think we can just decide on some kind of constant, decide on that for the— there'll be like an app-wide constant to use, maybe like Maybe like 40 or 50 users displayed on a map. If you want to see more than that, you could see like more or something, and then you have some kind of basically pagination at that point. Yeah, that seems good. Um, okay, so return list of— return 40 Sure, the number doesn't matter, I guess. Return capped, capped number, number of user documents. If— when would we not return a 200? Let me think about this for a second, because if there's no users found found in the city, that's still a 200.

Green Stingray: You're just going to return nothing.

General Centurion: Yeah, yeah, you're going to return a zero. Um, trying to think about when this function would be considered like, I don't know, broke, I guess. Maybe invalid city, invalid, invalid user. If there's no filter, that's fine either. We're just going to do an unfiltered search. Um, If there's no city, I guess, but the city should be like a mandatory field, I think. Yeah, so if they're missing— I would, yeah, I would make it, I would make it a mandatory field.

Green Stingray: Okay.

General Centurion: Yeah, otherwise 400, just a generic server error if Let's say we wrap it in a try-catch and it doesn't work for whatever reason, throws an error.

Green Stingray: That would be a 500 then in that case actually. Oh, 500. Okay, cool. Yep. Because 400 means the user made a mistake, which in generic server error you usually blame yourself, not them.

General Centurion: Oh, okay. I thought it— okay, cool. Um, okay, this is good.

Green Stingray: Now let's talk about the pagination. So you said this is like capped to like 50, right? Mm-hmm. Now, how then, let's say, again, the user wants to make a follow-up request to get more. Like, when do those— how do they get more? Mm-hmm. Okay.

General Centurion: So, there is the basic, like, sequential kind of pagination, and there's cursor-based pagination. I don't remember the specifics. I think cursor-based pagination takes up a little more memory or storage. It's almost like indexing, but it's faster lookup. Whereas something like the typical pagination would just be sequential. You go next page and it makes another request. Yeah. Okay. So it makes another request, meaning it doesn't know where the previous request was in the database. So it takes longer. But I think, I don't know, maybe that's getting too much into the weeds.

Green Stingray: I think, I think, yeah, anything that works basically. Yeah, I did whatever you think. Okay, sure, sure.

General Centurion: Um, so we just— yeah, so if we just do some basic pagination, then you would have, uh, request queries basically. That's how most people do it. You have a page and a count, page number, and then a count of how many you want per page. Server would handle that, so the endpoint would handle that. It would receive it would receive basically page 1 on the first load. It would be like, or page 0, I guess most people do page 0. Page 0 and then the count would be like some constant, let's say 50. And then if the user presses next on the front end, that would be like using React, you could have some kind of state for like the page, page number or whatever. And then the request, the endpoint would receive like a query parameter to say like page 1 and then page 2 and then page 3 based on what number you're on. And then yeah, on the side of the— on the side of the server, when it receives that query, when it says like page 2, you return the second like results number 50 to 100, basically.

Green Stingray: I think that's— yep, yep. So, um, And then you would just send like a skip and limit thing to the database.

General Centurion: Yeah, exactly. Yeah, yeah, that makes sense.

Green Stingray: Yeah, that is definitely— it— if the user gets really deep in there, if they get to like page 20, 30, it gets slower and slower the deeper you get. Exactly. Yeah, that's why people don't do it for like super complicated systems. But great initially, it's, it's fine. Yeah, for most use cases. Um, yeah, yeah, it depends. The power users. That makes sense. There's also a few quirks with that, doing a system like that as well. But no, no, that— let's say, yeah, skip and limit using, yeah, pagination seems great. Okay, so skip and limit pagination. Okay, any other interesting things to discuss? Okay, well, actually, almost— we're running a little low on time. But yeah, let's see, is there any other interesting things that you would have wanted to discuss as part of this?

General Centurion: Yeah, maybe latency. Um, yeah, so how do you handle— so you have like a million users every day and two people match and whatnot. How do you, how do you make that immediate? Or maybe even—

Green Stingray: what do you mean by that? Um, oh, like seeing data, like fresh data. I mean, so let's say, yeah, let's say like a match, right?

General Centurion: I guess, I guess, okay, I guess matches would be pretty easy because it doesn't have to be like, you don't have to use like WebSockets or anything for that, or even polling. Matches would just be like, uh, the way I would do matches is maybe you could have another, you could store something else on the document store on the users to see like How many users he has matched with or like said yes to, swiped right on. Yeah. And then when somebody, I get, yeah. Okay. I guess that's an interesting thing. If I swipe right on somebody and that somebody swipe right on me, how does that, how do we know that on the database?

Green Stingray: Because, mm, that makes sense. Yeah, totally. So I would probably do something like a matches table where you put both. Yeah, exactly.

General Centurion: Exactly.

Green Stingray: And I would probably do, I would probably do all right. To both users. Exactly, exactly. And so, meaning that like, so for every match I put it in twice. Mm-hmm. And you only then you'd only need to index on this one. And then to get the client to get the data, I mean, probably lazy polling is pretty common, like where, you know, you just fetch every 20 seconds or something.

General Centurion: Yeah, yeah, I think.

Green Stingray: And then you could also add a created timestamp here. Then you could add a compound index on user1,created. With this, what you can do is you can make it so you can do a very, very efficient query which says, are there matches for this user that are greater than this timestamp? Right.

General Centurion: Okay. Like a composite key, sort of?

Green Stingray: Exactly. This will give you— since it's all indexed, it'll be very fast. And generally it'll be no, there is no new matches, right? Exactly. And so that's a super lightweight endpoint. I mean, it's not ideal to query the server, like WebSockets is better for sure, but— It's just people and it's so much simpler. Yeah, exactly. So I would start with this and then maybe eventually move over to WebSockets. But yeah, you just have to pick your battles when you're designing something, right? And so— Mm-hmm.

General Centurion: Yeah, I think it also depends on the app design, what exactly you're going for. Does latency really matter in this case? Do you care if the match is like instantly?

Green Stingray: Yeah, I would say like even up to a minute, probably no one really cares, you know. It's like not getting that info right after it happens almost is a little weird, possibly. Like you match someone and they message you in like 2 seconds, it's like, whoa, that was fast. Yeah. Yeah. That is an interesting thing. Okay, cool. Cool. Well, I'm, I'm, I'm able to go over a few minutes on time if we need. Let's, let's move forward to just questions about like retrospective. Any, any questions you have for me about doing these kinds of interviews? Yeah. What, like, yeah. What's your thoughts?

General Centurion: Hmm. Okay. I guess one thing I'm curious about is What do you, what do you really care about in these interviews? What do you look out for? What do you, what really matters? What do you normally ask?

Green Stingray: So honestly, the weird thing with these kind of interviews is every single one's different because the, the, because the interviewer is different. Right. And so, but yeah, for me, I, I like database design of it cuz I understand database design quite a lot. And so I'll ask, I'll always ask like the schemas or which field gets indexed. Right. Mm-hmm. I think that's very fun. I think about networking a bit. HTTP status codes I care about a lot. Scalability, of course, because I just like to think about that. Performance and cost. And then, I mean, if we had more time, I would go into monitoring of the system. How would we know issues are happening, right? Like, are we— do we have a monitor tracking the API latency over time and would it alert us if it doubled or tripled?

General Centurion: Right.

Green Stingray: Yeah. Or the CPU utilization's like through the roof, right? Or things like that. Right.

General Centurion: I think there's so much we could have gone into.

Green Stingray: There's so much. So one thing, one recommendation I have is, um, is speed. It's better to be quicker than like handling like corner cases.

General Centurion: Um, you mean just, you mean speed in the interview or just like giving ideas? In the interview.

Green Stingray: So like, okay. Like when you talk about check rate limiting, like having a reasonable thing, like handling the DDoS case. Sure. It's out there. You could address, like acknowledge that it's there, but let's not worry about that for now. Let's come, like, you kind of like have to hand wave quite a lot of things as you're doing it. Okay. Like even rate limiting might be something you just hand wave across and be like, well, let's come back to that. Because these interviews are essentially a thing of breadth and depth, right? And you wanna make sure you cover all the breadth at least. Okay, yep. And then, and then you want to dive in depth on the things your interviewer cares about, right? Two things: one is the thing your interviewer cares about, and the other thing is the stuff you are the best at, right? So you want to demonstrate the things that you are very knowledgeable about, um, and then the interviewer will push you on things, um, and, uh, so, uh, but yeah, no, I'd say, uh, yeah, just going through it back, mostly just practicing, going to be able to go faster, right, to cover all the to get all the core functionality in. Cause basically you want it, we want to get through it probably like at like 40 minutes through the interview at least is basically say, I have designed the system, right? Like here we have something that works. It may have some like flaws, right? Um, but I have the core system designed in the, in the, like the first 40 minutes. And then you have another 15 for the interviewer to like poke holes at it and be like, well, I don't like what, what will happen if, you know, 10,000, you do a special day of like promotions and everyone signing up on the same day, right? And then, so then they'll like, you know, do, um, point out like flaws and weird things that could happen. Uh-huh. Okay. Getting you to tweak your design. But if you, yeah, you can only really do that if you get the design out there first.

General Centurion: So yeah, pretty much like, I guess what we did in like the first 10, 15 minutes, just got a very high level breadth first, um, of the technologies that we need to do and then kind of dive a little deeper and say like, oh, this relational database, what are we gonna do in here? What about the endpoints networking?

Green Stingray: How are we gonna handle that? Exactly, yeah. So, I mean, pretty similar stuff we have. Some might not want me to schema at all. I mean, different ones, but yeah, more or less this kind of stuff and just faster, basically, in my opinion. Okay. To leave more time to talk about some of these other harder things. 'Cause there's a whole laundry list of things that the interviewer might wanna talk about in one of these. Okay. And hopefully they'll, they should nudge you towards those things, right?

General Centurion: Yeah. Okay. How would you suggest, like, I guess being quicker? Do you think it was good to have some kind of like, almost like a cheat sheet in your head saying like, okay, this is what I need to cover this and that and that and that and that. And then you just kind of spit it out because for me in this interview, I think having that diagram or not like the The little media resources on the right kind of helped bring some ideas into my head. I think that was really helpful. So maybe I should just have those ideas in a real interview. If I didn't have that, I should have those ideas fresh in my head, I guess. Mm-hmm.

Green Stingray: I mean, cuz those are the building blocks. Yeah. So for your system diagram, yeah. For the chart, like design that. Yeah. Having that cheat sheet thing and then having like the basic API design, like, and then like I, in basically my, one of my things is introduce complexity when needed. Not just to introduce it. Right. And so there are things in that diagram, like the message queue, which are useful. And almost every interview will eventually have one in it. But it might not need to be in the first design. You know, or like, I don't, yeah. Like, but I, as an interviewer, actually, I, if someone does include a message queue and we have time, I will bring up a problem or statement or something that will require adding a message queue to make sure it's on their like idea list. Right. Yeah. Because everyone should be familiar with them, but you also just don't necessarily need them to solve issues. So yeah, having like some just like back of the napkin things and like, honestly, like mo— many, many problems boil down to CRUD. Yeah. Okay, cool. And this, I mean, honestly, half of this problem is just a CRUD problem, right? It is. Yeah. And so almost any question that's a CRUD, like create, read, update, delete, right? And so, you should be like basically like, okay, someone just wants a highly scalable CRUD system, here it is, you know? And so, there's details, of course, but like— but yeah, you should be able to just produce a CRUD. And then you think of like, okay, where does it differ? What makes this unique, right? But only spending your brainpower on the things that differ. And so, I would say When you introduce a problem, just think beforehand if you're going to do DocumentDB or relational if it doesn't matter. The one you should pick is the one you're more familiar with. On the caching side, we didn't talk about it, but usually you'll end up wanting to bring in in-memory cache, one of these things like Redis or Cache. Then if you bring that in, so for every technology, you should have a default one that you're going to use unless the system mandates otherwise.

General Centurion: So like Redis? Um, yeah, exactly. Okay.

Green Stingray: And then, and then if like, and you say like, this is familiar, it has its good things and you should be able to list off like why it's good, but don't be like, and like, but if the interviewer is trying to do off of it, listen possibly, right? Um, yeah. Okay. But it's just easier to have a default. Right. And like when I, when I pushed you on like what language you actually, you like, you went pretty quickly to Node.js, right? And that was fine. Right. Because it doesn't matter what language you use there. Having defaults for most of the core things will help because otherwise you get, you know, you have too many decisions.

General Centurion: Yeah, okay, that makes perfect sense. In this case, what would you say the in-memory cache would like play a part in?

Green Stingray: When, um, quite possibly on the heavy cities, right? And so if you are the getNearbyProfiles, if that endpoint starts getting slow You could make it so the first page is the same for everyone when they load it in a city. Okay. Oh, yeah. It has some flaws that like, okay, everyone's seeing the same 50 people at first, right? And so, there's quirks there. But— or even just like if there's a certain user that are calling this endpoint too frequently or something, right? And like so they're refreshing excessively, you could— cache them as well to avoid hitting your— yeah, that would be the main thing I would use it for. Or yeah, like, I guess you could also on the matches side, you could store like recent matches in the cache as well. True. Okay. To avoid having to hit a database for those. Yeah, there's a lot you can cache. Yeah. So yeah, but overall you add caches when your database is getting hot, right? If your database's CPU is getting too hot, it all— yeah, then you like throw that in there. Or the other way cache would be is the more common actually would be for rate limiting. Um, okay, you like to put an IP address to, to the time or to count, and you put some sort of expiry on it. And so you could prevent someone from doing a signup more than like one every 5 minutes very easily with Redis cache.

General Centurion: This auto does an expiration. Yeah, okay, I'll keep that in mind.

Green Stingray: Yeah, so that would generally be the default people use when they rate limit. They just use some key in a cache and have an expiration on it. Mm-hmm. Yeah, so that— okay, is there any other defaults that would be worth mentioning? I think that's mostly it. Oh, at some point in a future time, we didn't go into auth at all, but you should have a slightly better story for how you do auth by default. Mm-hmm. If it is part of the problem, like with this one, I was like, it's not a core part of this problem, but, um, I would say you should be familiar with ways of doing it if you're not familiar, like creating like a password column. Like if you do have a password, how does it work in a users table? Have you done that before?

General Centurion: Oh, I guess with the hash and encryption stuff and transit encryption, more so like you create like, um, what is it even called?

Green Stingray: You like, uh, Salt, let's see, no, you have a password, if you have a password, you don't store the password in plain text, right? You don't ever do this. That's no good.

General Centurion: Yeah.

Green Stingray: You always, you do hash it. It's a hashed password. Yeah, exactly, yeah. And honestly, it's pretty simple. You just hash it with like a SHA-256 or something, right? Yeah, exactly. And so, okay, but yeah, so if you needed to do auth, you could do it pretty easily with something like this, right? And then, and then you can also do it where, and then tokens. Yeah. So I'd say, yeah, I'd recommend before you do an interview, like, yeah, you just look, explore around with that alone. But yeah. And then just keep kind of like playing around with more systems that you're kind of familiar with. And then watch, and then you, have you watched any recording? There's a bunch of recordings here online of other people doing system interviews, right? Yeah. Yeah. Yep. True. So yeah, just, just the more experience, but honestly it's, it's, it's a, this is a tough thing. The goal of a system interview is to see if people have experience designing backends. Okay. Yeah. Fundamentally you don't, because that's not your goal. Right. And so it's a funky interview to do. It's kind of unfortunate, but you've, you've, you've worked with backends and so you're familiar.

General Centurion: Yeah. Yeah. Yeah. I've, I think also just project experience goes a long way.

Green Stingray: Yes, exactly. Yep. Yep. And just having that design. Yeah. So no, totally. So yeah. And, but yeah, just with your interviews, always like make sure that people know that you're, you're a frontend per— you've done mostly frontend, right? To set the right expectations a little bit. You know, they'll, they'll be a little more guiding. Yeah, okay. Any last questions before we end?

General Centurion: Um, I think I'm good on my end.

Green Stingray: Cool. Okay, awesome, awesome. I'll write up a little feedback as well. Um, yeah, no, um, good work. Sorry, I know it's all over the place with these kind of interviews. I've never had that happen before, so that's okay. Okay, well, have a good rest of your day. Okay, thanks.

General Centurion: You too. Thanks so much. Have a good one. Take care.