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

System Design: Dating App Backend with Geospatial Search

Watch someone solve the the problem: dating app backend (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: Dating App Backend (Medium)

Interview question

Design the backend for a dating application where users can log in, manage a profile, view nearby users, and maintain a favorites list. The system must support 1 million daily active users, prioritize availability for location-based queries, serve fresh real-time location data, and handle geospatial proximity searches efficiently — all without a matching system.

Interview Feedback

Feedback about Massive Lightning (the interviewee)

Advance this person to the next round?

Yes

How were their technical skills?

3/4

How was their problem solving ability?

4/4

What about their communication ability?

3/4

Strengths: * great breadth of knowledge & good understanding of backend distributed systems * largely able to focus on the interesting parts of the problem * quick at designing and discussing, so we were able to go through the whole problem which is great Areas for improvement: * it would be good to be able to provide more details about the technologies you use. e.g. when saying you're going to use redis, describe your key format and what the values will look like. For the DB, the schemas and queries could be more specific * find ways to demonstrate your depth of knowledge during the interview Advice: * try and keep your notes and ideas organized during the interview. Definitely worth using the whiteboard and I'd definitely recommend familiarizing yourself with the whiteboard tool Excalidraw. It's the one embedded for these practice interviews. * watch videos and read docs about the common technologies that you'd want to bring in (e.g. Postgres, Redis, Kafka, Kubernetes) * also bring lots of energy to interviews to keep the interviewer engaged, I thought you did pretty well with this, but it's something I think it's always worth reminding about

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?

4/4

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

4/4

Great interviewer! Thought he cut the balance between collaborative and challenging quite well!

Interview Transcript

General Centurion: Hello, good morning. Can you hear me? Hello, can you hear me? Hi, can you hear me? Yes.

Massive Lightning: Yes. Hey, how are you doing?

General Centurion: Not too bad, how about you?

Massive Lightning: Doing good, doing good.

General Centurion: Awesome, great. Okay, so I usually start with about like a quick little intro, maybe like under 1 minute each. And then we have the vast majority of time to do a practice question. Um, does that sound good?

Massive Lightning: Uh, yeah, sounds great. Great.

General Centurion: Okay, so I'll start. Um, I've, uh, been at a bunch of different, uh, companies in, uh, industry, pretty backend focused, uh, moved more into infrastructure. Um, been at large places like Google, Stripe, uh, Airbnb, and then some smaller startups as well. Um, yeah, so that is me. And then with your intro, if you can also focus on what you're hoping to get out of this.

Massive Lightning: That would be helpful. Yeah, so my name's [REDACTED]. I've been primarily working in startups for a little over a decade. Was a founder for like 2 years, was at [REDACTED] for like 2 years. Currently at a chip design startup. We build, we apply AI to mixed signal and analog chips. Trying to get back to, you know, basically trying to get like, you know, I'm trying to get prepared for interviewing at the [REDACTED]. So mostly, I haven't really done a lot of system interviews. So I just do some, I guess, like some dry runs to see how well I'm prepared.

General Centurion: That makes sense. Okay, great. So pretty early on in your process, trying to get a baseline. Okay. I mean, with system design interviews, there's really kind of two overall of different kinds of questions that people largely ask. There's ones where it's like kind of a broad question where you're trying— you're designing more or less like an entire application. And then there's ones where you're designing a particular service in more depth. Do you have thoughts on which one you think might be more helpful to practice?

Massive Lightning: Which type? So I've been doing a lot of like the [REDACTED] ones, so I don't know of those. Why don't we go with one of the sort of the broader ones? Because I think that's kind of where I'm— yeah.

General Centurion: Sounds great. Okay. Let's do it. Okay. I've got a good one. Let's see. The goal is to architect the backend for a dating application where users can log in and see other nearby users. And so to keep things simple, we're not gonna have like a matching system at all. The features, they like, basically they should be able to features, manage a profile, And then, you know, view others, and then a nice-to-have would be like a favorites list.

Massive Lightning: Okay, great. So functional application. So the functional requirements are basically like manage a profile and have a favorites list, right?

General Centurion: And then see nearby people as well, yep.

Massive Lightning: OK, so manage profile, favorites list, see nearby people.

General Centurion: Mm-hmm.

Massive Lightning: OK. And do you want me to sketch out the non-functional requirements, or—

General Centurion: Sure. Yeah, that'd be great.

Massive Lightning: Yeah, OK. So I'm gonna assume this is like fairly high, fairly high, fairly high scale.

General Centurion: So yeah, let's say there's like 1 million daily active users.

Massive Lightning: Okay, 1 million daily active users. Like maybe managing, maybe this should be like fairly low. I guess if you're managing a profile, you want to have like, you know, like strong consistency. But if you want to see people near you, then you, you probably like your availability over other considerations.

General Centurion: Yeah, so by and large it's like availability is more so, yeah, but only for your own data. Yeah, good. Yeah, that makes sense.

Massive Lightning: Yeah, would you care specifically for everything else and maybe it should take like less than, I don't know, 50 milliseconds, or let's, let's say like 300 milliseconds to like load people near you.

General Centurion: Yeah, that would be reasonable. I was like, yeah, I think 50 would be nice, but that's, that's more than people— that's, that's with applications on anything under like 1 second is considered okay.

Massive Lightning: Yeah. Okay. And, um, like how, how real-time are we? Like, like, like, is this gonna be something like the, you know, apps application on the phone, or is it like—

General Centurion: phone? Yeah, this will be— imagine that. Yeah, it's like pretty fresh. We want— like, we were trying to have fresh data.

Massive Lightning: Okay.

General Centurion: People might use that like at an event or something, you know, who's— yeah.

Massive Lightning: So, okay, okay. Um, do these non-functional requirements look good, or do you want me— can I continue?

General Centurion: That's great. No, I think that's good.

Massive Lightning: Okay, great. Um, so obviously, uh, I would say like users Within the users, I probably want to fold in personal information and maybe preferences. And then, or we can even say profile and then profile and then within the profile there might be preferences. And then, um, and then within a profile there could be like, you know, you know, a location. Like, we could, you know, emit a location for every single, um, place that they've been. Um, I think that's just like easier. It's a little more Orwellian, but, uh, it makes it easier for us. So, um, does that—

General Centurion: is this unreasonable or Yeah, no, seems great.

Massive Lightning: Okay, so I would say for the API, um, you'd obviously want to be able to like create a profile, um, or then we would want to be able to update the profile, and this is for like the user zone, um, and you know, things that Name, preferences, you know, location, lat, or this. Hash profile. Name, email, patch. Make it be like, uh, sex. Um, uh, so we're just kind of like going, going through it.

General Centurion: Yeah, kind of the basic filters.

Massive Lightning: Yeah, no, totally. Yeah, yeah. So Like age, sex, distance, I think would be pretty normal. And then like—

General Centurion: Yeah, I think that's a good starting point.

Massive Lightning: Yep. And then I guess if we want to create locations, we would just post the lat-long. Mm-hmm. Yeah. Sorry, this is— and then, you know, we could periodically post it and then obviously the user IDs and the header, either the header or the JWT or something like that. Yeah, that makes sense, yep. And then I would say the really big one would be getting nearby users. Yeah. So this would be like a GET. So I guess it would be get like— we could call it getNearby or we could call it like getProfilesNearby or something. I think for the sake of consistency we can do— We can do something like, let's just do like getNearby. And then, and then what it does is that it'll just return like, you know, a list of profiles that like match our Preferences that match both our preferences and like the users, like the other preferences of the other users.

General Centurion: Yeah, yep.

Massive Lightning: Okay, um, does this look good or can you— can I move on or—

General Centurion: yeah, no, this is great. Yep, yep.

Massive Lightning: All right, so, um, I would say for the high level, sort of like a high level design, uh, there's gonna be some sort of client with the user, sort of like API Gateway, and then— It seems to me that, you know, you could probably keep the, you know, you could have like two. Okay, so it's feeling to me like you would want like two different services for this. So I guess we could have, like, a profile service.

General Centurion: Love it.

Massive Lightning: Which, you know, maybe hits, like, a Postgres DB with the profile information. And then you could have a location service. Service which hits another datastore. I mean, the two things that are kind of popping out are maybe Cassandra or DynamoDB. I think that we are writing a lot to— I mean, I think both of them are probably pretty reasonable. I think I'm inclined to just go with Dynamo because I think you can like service the last one. You mean the scale is such that like it's not so high that writing to Postgres wouldn't be unreasonable either? Mm-hmm.

General Centurion: I think Dynamo would be the interesting choice here. In that it will be tricky to make it work correctly. But I would— I think Dynamo, if you make it work, it'll be better. But no, you can use anything here. But yeah, what do you— what are you thinking? I guess I would think a little bit how you're gonna power that getNearby, right? Yeah, yeah, like, yeah, I'd say like, yeah, but yeah, because it's non-trivial how to do that.

Massive Lightning: Yeah, yeah, yeah, yeah.

General Centurion: Also, wait, does getNearby— you could— it might be simple. It's just, will this take in the current user's lat/long, or will that do a lookup? I guess, I guess it doesn't really matter how that works.

Massive Lightning: Yeah, yeah, yeah. So the user info is like determined by the header or the JWT.

General Centurion: Yes, yeah, yeah. And then you know when they—

Massive Lightning: where they last were.

General Centurion: That makes sense. You have all the info you need for it.

Massive Lightning: Yeah, yeah. Uh, now that you are kind of like, um, hinting at, you know, sort of the problem, like, I, um, you know, I think like the sort of like brute force version is just to use Postgres and do something like PostGIS, um, you know, or, you know, Elasticsearch if we're like feeling very risky, because like the main thing is like you're trying to look up like nearby users and that's, you know, sort of a function of like, you know, are you using whatever like geographic indexing, I think like PostGIS is like more like R-trees or something like that. And you're basically just like looking at the last live location and then like trying to do like a nearby query on that. So you could use PostGIS or like some sort of like geocaching things, like I don't think that like, if that Does that sound reasonable, or?

General Centurion: Yes. No, I think that sounds much more reasonable than trying to go with Dynamo, because it does not provide anything like PostGIS out of the front. Yeah, so I think, yeah, I think, yeah, no, I think using some leveraging, some existing ability of handling locations would be very valuable for this.

Massive Lightning: All right, profile and location.

General Centurion: OK. Nice.

Massive Lightning: All right, so the way I see it is that, you know, the user will first, you know, provide an update to the— you know, the user will, you know, sort of make CRUD updates to the profile service, and then that gets stored in a profile table. And then over time as the user walks around, whether they have the app open— let's say like whenever they open the app, right, then it starts sending out—

General Centurion: Yeah, I'd say only when you have the app open, that would be reasonable, yeah.

Massive Lightning: Periodically, and it loads the last location. And then so basically, the most naive way is that whenever They want to get all the location, their app makes a request to the nearby API and then we just do a query in that geography based on what their max distance is. Or maybe even if we want to optimize it, it can be like restricted to the, you know, the size of the viewport.

General Centurion: Yeah, yeah, that's interesting. Yeah, let's see what your tables look like and what that query would look like.

Massive Lightning: All right, so, you know, so obviously like profile name ID, I'm just gonna copy this here. Oh yeah, yeah, location would be like—

General Centurion: it would be nice to put your, the data types on those.

Massive Lightning: Okay.

General Centurion: Most are somewhat implied, but nonetheless, it's just to be specific.

Massive Lightning: Yeah. Um, or we could even have birthday.

General Centurion: Hmm, that's probably smarter. Yeah, because then it stays fresh.

Massive Lightning: Yeah, good point.

General Centurion: I like that more. So, you know, depending on your data type, I would expect you have like an enum there of some sort with open—

Massive Lightning: Yeah, yeah. Okay, and then we can have this be like meters, you know, meters.

General Centurion: Nice, okay, yep, yep, yep.

Massive Lightning: And then UUID, lat, I guess we can call it real, real user ID, UUID. Created at datetime. So this is what I would— this is kind of like what the table would look like. I guess the query to look— select star from users. There's, I guess it would be like, I don't remember how to, I don't remember all the query syntax offline, but it would be off the top of my head, it would be something like join the last for, you would basically be getting all the locations that were created, um, uh, get all locations created, uh, after certain cutoff time.

General Centurion: That makes sense. So it's like a fresh location. Yep.

Massive Lightning: Within, within user location. Um, and obviously like, uh, the lat/long will be like indexed On geograph or rtree. Yeah, so, so this will instantly like cut— yeah, uh, like cut this down to some something, um, more manageable.

General Centurion: The query planner can very efficiently query on this, but the query planner, by the way, you know, generally indexes, uh, like— so yeah, if you can very efficiently query on your lat-long, correct? Yeah, but you're saying also you're filtering on created_at, and so Postgres will Well, it could use multiple indexes, but that's going to get messy. Yeah.

Massive Lightning: So yeah, yeah, yeah.

General Centurion: I mean, and then if you're saying you're doing a join as well with the profile table, now we're talking even more messy, right?

Massive Lightning: Yeah, yeah. So I would probably do like create it after a certain cut off, and then within a certain user location, then join to profile and return. And this is probably not super great at— if we're looking at 1 million DAO, you can do stuff like replicas and caches, but it will probably be pretty not pleasant to work with after you know, even like a couple, you know, tens of thousands or like hundreds of thousands.

General Centurion: Yeah, the replicas, you could survive with enough replicas and caching. Yeah, uh, but yeah, the better we can make this, the more performant we can make it, the better, obviously. Um, let's see, I think, um, I think in the hottest query you don't usually want to join. I would say that.

Massive Lightning: Yeah, yeah, yeah, yeah. So I, I would I would say that the next thing that kind of pops up is we could use Redis for active locations because if there's no need to do the sort of Orwellian persistence of trails, then doing a query of who's actually active, right? Mm-hmm.

General Centurion: I think that's good. Do you need to use Redis or could you still just use this database but using that idea, those principles?

Massive Lightning: Uh, yeah, yeah. I mean, is, is there like something like a TTL for, um, Postgres? No, no.

General Centurion: Uh, there's, I mean, well, with some extensions there probably is, but out of the box, no. But you could build it pretty simply.

Massive Lightning: Um, can I, can I just assume that like we have like a TTL like extension that we can just install and it's like performant and like Is that reasonable?

General Centurion: Probably. Let's just describe quick. Let's say you don't. I think it's pretty simple to describe how you would create one.

Massive Lightning: Okay. I mean, like the sort of like the simplest version I could think of is like you just have a cron job which goes in and like cleans up. Location after like a certain, you know, time.

General Centurion: And then like, for that crime to be efficient, it needs what in the database? Like, what indexes are on this? You said that this is indexed here, right?

Massive Lightning: Yeah, yeah, yeah. So like, we could create like a TTL timestamp, but like, you know, we could just like fix like a certain, like after a certain date, we just, after a certain time that like, you know, we remove it, right? So then you would have, you could have like a range, you could have like a, like another index on the datetime.

General Centurion: Yeah, that, that alone would make it fast probably.

Massive Lightning: Yep. Yeah. Um, so, um, I'll just like make sure that, you know, old location cleanup cron. Is that—

General Centurion: Mm-hmm, yeah, that's reasonable.

Massive Lightning: Yeah, so that, you know, that— so basically, like, we can kind of get rid of one of these joins, so Get within user, get all users within user location, join to profile and return. So we still have like one join here, which is like kind of satisfying.

General Centurion: Yeah, how do we get rid of that?

Massive Lightning: One kind of One way is denormalization. So like whenever we like update the distance, like we like process a bunch of like profile information that like we serve to the user beyond just the user ID. Does that—

General Centurion: Wait, yeah, I like the normalization. When you say, okay, so let's say someone changes the other distance. Well, distance is actually probably the, yeah. Let's say someone changes their age, min— yeah, I guess, yeah, some of these settings, any of these settings really, what do you do? Yeah. What specifically happens?

Massive Lightning: So, so here we're dealing with a case of like, it's like a sort of eventual consistency. So, the, you know, if we do normalize, like, we do get performance, but then, then, you know, we're sort of dealing with, like, you know, eventual consistency concerns where, like, you know, we're trading off, like, speed for, like, updating. So the downside is that, like, you know, if a user updates their preferences, it might not be immediately reflected. So one thing that we could do is that on the client, we could, you know, do a second check to make sure that, like, the profiles that are, like, getting in are don't like actively violate any of their state preferences. Mm-hmm, yeah. I like that. Yeah. And like one of the drawbacks is that they might not see all of the profiles that are available, but they won't see anything that's like actively so that they don't want— yep, yep, yep, yep, your profile. So then they want to see, um, other people might— what?

General Centurion: Oh wait, yeah, keep going.

Massive Lightning: Other people might see the profile they don't want to see. Uh, so like, that's like a security concern. Like, that's a potential security concern. Until like—

General Centurion: I guess, is this— how big of a deal is this eventual consistency here?

Massive Lightning: Um, I think that's like a product question. Um, like, your— if, if this is like some— if this is like a low-density, you know, or like low, uh, or like a niche, you know, community, then I would be concerned about like squeezing out every single match possible. If this were like a larger general thing, then, um, you know, I would probably care less. I mean, like, we stated that this is—

General Centurion: I think this is by category, like, I think in general we're talking like seconds or milliseconds, right? And so Uh, I just don't think it's that big of a deal. I think it would be— I guess if the consistency is— what would you imagine it would ever be more than? Like, I mean, anytime you're using reader replicas, right away you always have a consistency potential issue. Um, but same with you when you denormalize a little bit. Also though, I think actually would— so when you— when someone updates their profile, do you— I think you only have to update one location as well.

Massive Lightning: Yeah.

General Centurion: Right, and so could you— you could probably actually just update both in the same transaction or like, um, at the same time before you even return, and then there's no issue at all.

Massive Lightning: Yeah, you could like in the update you could also look for any like outstanding locations and like invalidate it.

General Centurion: Uh-huh, exactly. Yeah, yeah.

Massive Lightning: Active, then also invalidate. And this kind of gets rid of the— well, you could have the cron job as kind of like a backup.

General Centurion: Yeah, and then the backup. Yeah, so okay, so if something goes wrong, then yeah, the cron will clean it up within, yeah, whatever, an hour, a couple hours or something. Yeah, yeah.

Massive Lightning: Yeah, reduce, uh, occurrence, reduce latency.

General Centurion: Okay, and so with the denormalization, are you basically saying copy these columns onto the location table, or is there a different way you're thinking of doing it?

Massive Lightning: Uh, yeah, I mean, I think the most vulgar or the most simple way is just like copy, you know, You know, like, you know, you could just have like a profile JSON and then like—

General Centurion: Oh yeah, yeah, yep, yep, yeah, yeah, okay, that— okay, so we're in alignment. Yeah, okay, um, yeah, whether that or you could have a column for each, it doesn't really matter, but this one's cleaner though for sure. Yep, yep, okay, that makes sense. Yeah, now your data is right where you need, and then you have no more join, right, because the profile JSON is right here. Uh, yep, yep. Okay. Then let's see here. This makes sense. I think we've been nearby. I feel pretty confident that now it'll run reasonably quickly. Let's say, yeah, is there any other interesting things to call out here? What if the database is still— you're doing this without the join now. You're able to run it with a bunch of reader replicas. It's running not too bad, but you're wanting to now make it a little better at the cost. You hear from product that they're like, consistency is not our big deal. We want to save money now. We're growing. We're a victim of our own success. And now, you know, but we don't want to 2x our database cost in the next year when we double our size. So how could you, you know, increase capacity and throughput without increasing cost? And the product is, you know, we don't need perfect consistency anymore.

Massive Lightning: Okay, so So then the question is like, how much can we relax consistency and still get away with it? Obviously I think you want to be like somewhat like more aggressive. You know, you could have the cron, hmm. Okay, so this is primarily a storage problem. I think that you would want to figure out ways of purging location as quickly as possible. So when you are updating the location, not only do you not mark it active, you just wipe it, right?

General Centurion: Oh yeah, yeah, no, I like that. Yep, yep. And I, yeah, okay, totally. And when you say, so, okay, so a customer sends you their new location, what do you go and delete their old one? Is that what you're thinking? Is that the idea? Yeah.

Massive Lightning: Yeah. Okay.

General Centurion: Totally.

Massive Lightning: Like I would spin this as like, not only is this cost saving, it's like better for the product. Cause then you can like say something about privacy, right?

General Centurion: Yeah, it is exactly. And your data is just cleaner overall. Yeah. I like that a lot.

Massive Lightning: Yeah.

General Centurion: And privacy is good. Yep.

Massive Lightning: Yeah, I don't think that— yeah, I mean, I don't think that like running like a— like whatever, however you're hosting your job, like on Farcaster or like EC2, that like running it more, or if it's on a Lambda, then yeah, you don't want to— maybe you could like— but I feel like running this, this is probably not a huge cost driver anyways. The other thing I would think of is like, what data could I strip out But this is already pretty bare bones, but like—

General Centurion: Pretty bare bones, yep, yep.

Massive Lightning: Yeah, you could like—

General Centurion: What about caching outside it? Like things that you could do external to the database?

Massive Lightning: Cache. Oh, right, right. Yeah, so the simplest thing to do is I think you would want, you could add a Redis server or Redis instance.— in front of the location service. Obviously, this has like— this will prevent— this will prevent some— this will prevent like some load. Because it's possible that a user might open it and repeatedly refresh it.

General Centurion: Yeah. Totally.

Massive Lightning: Yep, yep. So, this would sort of prevent Obsessive refreshing. Mm-hmm. The other thing you could do is you could shard it by location or, like, large geographic areas. I don't know that this, like, reduces cost that much, but it would reduce latency.

General Centurion: Mm-hmm. Kind of, yeah. Increase your data locality a little bit. Yeah, tricky because the boundaries though, right?

Massive Lightning: Yeah, yeah. So like I would probably do it on like some sort of like continental basis. That makes sense. Yeah, um, like this doesn't— yeah, it doesn't—

General Centurion: that would definitely give you quite a lot of value probably because just the way indexes, these geoindexes probably work.

Massive Lightning: Yeah. Uh-huh. So, I don't know that we have like profile pictures here. I mean—

General Centurion: Oh, yeah. So, that was actually one of my follow-ups. This should have profile pictures, right? And so, I would love to hear at some point how you want to add that in.

Massive Lightning: Yeah, yeah, yeah. So, obviously, like the sort of like S3, you know, we want to have some sort of like blob service like S3. Mm-hmm. And Oh God, no. Sorry.

General Centurion: So there is, um, uh, there's a whiteboard, but I think you're doing great with this. But yeah, uh, this, this does show how the whiteboard would be helpful. I could see there in the bottom left there is one, but I think keep with what you're doing.

Massive Lightning: Oh yeah, so basically, like, you know, you have S3, uh, you know, the client queries S3 directly. Um, uh, like, whenever, you know, we create a profile, um, you know, the profile service then queries S3 to, like, generate a pre-signed URL, which is passed back, and the client does do the upload. So we would want some sort of S3 profile URL. When we talk about how to increase throughput, one of the things we could do is compress the pictures or only serve—

General Centurion: Oh, yeah, yeah.

Massive Lightning: Yeah.

General Centurion: That makes sense. Yeah, lower quality will definitely—

Massive Lightning: yeah.

General Centurion: Less traffic, yeah, less network volume, yeah.

Massive Lightning: Yeah, so like obviously we don't want to like ever stream the pictures through the service. Um, yeah, um, and then, um, I guess like one sort of like nasty side effect is that whenever we get the location, we may need to re-query the profile itself in order to get the actual full-size one, but we could just embed the profile pictures, use presigned to Avoid data streaming. Compress pictures. We could, we can like embed like a very low quality version on the location one.

General Centurion: What's the advantage of that?

Massive Lightning: So we don't need to fetch again in order to— so that we don't need to fetch— basically, in order to retrieve the more high-quality one, you would need to hit the profile service in order to generate the S3 location for the—

General Centurion: Oh, I see. I think you should store the pre-signed URLs. I don't think you should keep generating these pre-signed.

Massive Lightning: Okay, okay.

General Centurion: I think, I think you're gonna constantly generate these pretend URLs. That's gonna suck. Yeah, yeah.

Massive Lightning: I mean, I was thinking along the lines of like security, but like, I guess if it's like a picture on a dating site that's like 200 by 200 or whatever, like that's not that big of a deal.

General Centurion: Yeah, I'd agree. Well, and then you, and you, these can have like, uh, some sort of TTL. Usually when you do them, you can sign up for like a couple hours or something, right?

Massive Lightning: Yeah. Yeah, and then I think, yeah, you'll save a ton with that. Yeah, and then like, I think, you know, depending on how, uh, our infra budget is, it's like obviously the next thing is like, okay, do we have a CDN or not? Um, but like, you know, we kind of— product is saying that we want to cut costs, so, uh, probably not from cost.

General Centurion: But like, probably not.

Massive Lightning: If we're in for Indra, I'd probably at least try to like ask them.

General Centurion: That makes sense. Using pre-signed URLs is almost CDN-like. Uh, oh, that's CloudFront. If you have a CDN in front. Okay. Yeah, no, that's true.

Massive Lightning: Okay.

General Centurion: That was it. Let's move on. Uh, yeah, I feel pretty confident with your profile picture design. Yeah. Just as long as using S3 URLs and generally you want to store the pre-signed, like it actually is non-trivial to keep generating these over and over again. Um, okay. Then what about the favorites list? How would you handle that? Like, uh, adding favorites and then, um, yeah, like —getting—

Massive Lightning: Yeah, yeah, yeah. So I think the clean thing to do is probably just to add a favorites service. Or you could make the case that it's just another part of the profiles service. So I think the most naive thing to do is, hey, get— get favorites. You're looking at profile. Yep. User info or JWT, and then I guess it could be like put favorites. Profile ID, and then maybe, so it's like delete, I think it's just delete. Yeah. Profile ID, and then what you could have is you could have a favorites, favorites, where it's like ID created by favorite UID, UID. I think like one sort of issue I would raise is that like, you know, we haven't really called out like deleting or like inactivating profiles. So we would have to do like a join. I think like right now we can just assume that like, you know.

General Centurion: Yeah, let's not dive into that too much. Yeah, that'll—

Massive Lightning: yeah, I think, but it could call out for sure. Yep. Yeah. And then, yeah, I mean, I don't know that— let's say the person's ridiculously obsessive, right? Even if they generate thousands, it's still like— looking at their favorites I don't think is that hardcore of an endpoint versus— Sorry, I should have opened the whiteboard. But it's not that hardcore of an endpoint, I think, in comparison to like location service. So I wouldn't necessarily optimize too much on that. I mean, you're just trying to— I agree.

General Centurion: Yeah. Yeah. Yeah, no, that makes sense. I think this is a reasonable design. Yeah, no, I think— 'Cause generally, especially if you cap the favorites to some number, right? Yeah. But no, overall this seems good. Yeah, no, I think you're right. Okay. And then as far as ensuring reliability and resiliency, how do you keep the system running smoothly?

Massive Lightning: Yeah. Uh, so I mean, I think it's like you would, you'd want to like run in high availability mode like where you can. Um, I would say that the first, you know, the, you know, it's like, you know, you want like, I think it's like replication is like the sort of thing that, you know, you replicate app servers. Um, and the database, database servers. You have it, you know, basically like high availability.

General Centurion: Totally, like you run 10+ copies of this or whatever. You have the— and then with that— oh wait, okay, describe more what this means.

Massive Lightning: Yeah, yeah, basically you just have like a kind of like a hot standby, like write thing, and as soon as like, you know, you detect that, you know, it's down, then you like swap it in and like You know, you could have some stuff like, uh, you know, monitoring observability where it's like, oh, you know, do I have enough traffic here? Is this insane? Like, oh, it just dropped like 30% in like last 5 seconds on very peak hours, so like maybe we should like, you know, swap that in, right? Um, obviously like as we, you know, add sort of more things, uh, you know, there comes the issue of like managing it. So you have to like consistently hash to make sure that like, you know, we're requests kind of go to like the same spot that you expect. Normally this would be abstracted out, but like, you know, you have to think about stuff like Zookeeper if you're like managing your own cluster, you know, or running— we're managing it for more, um, by hand, right? Or like more at a low level. Um, uh, what else? Um, uh, I guess you would probably want to run backups. I mean, I don't know that this is like You know, this really helps you with like availability, but like, you know, if everything's good to have for sure. Yeah, good to have. I mean, depending on, you know, cost, like obviously like the considerations for this would be different than a trading system or like, you know, sort of like, you know, military thing where it's like, oh, you know, we have to have everything, you know, factored down to the second, right? You could probably be a little bit more lacks here, but you know, if I were, you know, the CTO, I would want to have some story there. For sure.

General Centurion: Yeah. Just issues happen. AWS could have, yeah, some sort of catastrophic thing. Um, that makes sense. And then what about for like data analytics? Um, speaking of like, yeah, if you're a CTO or like, you know, uh, how do, how do like, uh, let's say if a data scientist, how are they going to get reports of like, uh, activity and stuff like that?

Massive Lightning: Yeah, yeah, yeah. Um, Yeah, my sort of first instinct would be to try to like stream it to some sort of like data lake or some sort of like offline storage, and they can go muck around with like, you know, Databricks or some sort of like— I just don't want them to be like messing on the main system.

General Centurion: Totally, that makes sense.

Massive Lightning: Yeah, stream off to Databricks or S3 or something else off prod. You know, maybe they would have some sort of data pipelines running against the real thing which runs nightly. I think this is like— yeah, I mean, I haven't done a lot of data engineering, but this is what I would kind of assume.

General Centurion: No, what you're describing is very reasonable. Yeah, exactly. Some sort of nightly exports that as long as you're fine with somewhat stale data, that's Very good. Um, streaming is more complicated. Usually people, it's like, there's kind of a thing where usually people start with just, they get access to one of the reader replicas, like your hot standby or whatever, right? That has a full copy of the data. Usually hitting queries against that is fine initially. Right. Um, and then eventually you have to move to nightly and then eventually you want real-time streaming. Um, and so no, everything you're saying is great. Um, great. Well, those are, okay. That's pretty much the question, to be honest, I think. Um, Yeah, that— and those are most of the things I would call out. Yeah. So, I would say anything else that feels important to discuss? What do you think?

Massive Lightning: Yeah. I mean, I would feel like caching is kind of like the, you know, when we do do this, like we have to be pretty militant about the caching validation. Yeah. Yeah. Yeah. I think you didn't quite describe—

General Centurion: But the— I guess, well, the problem is, like, you mentioned that with the caching that you could cache for, like, a specific user that's refreshing, right? Their payload. But could you have cross-user caching at all?

Massive Lightning: Um, I think it's like, if it's like how I would approach cross-user caching, is that, like, if there's a location where people really, really like. But then it makes it hard to enforce preferences and that have to be done.

General Centurion: That's what I was thinking too. I was like, because I don't know, everyone has different preferences, so it's odd. The odds of a complete exact match is unlikely. Yeah.

Massive Lightning: So then it's like, you know, given the scale of this, I think it's unlikely that it would benefit a lot unless it's like a sort of like dating app where people go to like the same location, right? Um, and then, and then it's a question of like, do you trust the client to filter it, right? Because I'm like, you know, I think like you could make the reason— like, is this sort of like somehow like a huge enough concern performance? You could make the case. But then it's like, okay, like what if there's adversarial case, like someone just like hooking like, you know, a man-in-the-middle thing and just like, you know, streaming data? Like, I would say that that's probably not that huge of a deal, but, you know, Oh, yeah, they're hitting your APIs directly or something.

General Centurion: Yeah, yeah, that makes sense. But you're right, good call out that you could do— your endpoints could be more broad and then you could do client-side filtering and then put people— and then, yeah, okay, that's true, you could. And then that could increase your chances of having, uh, cache hits by, um, yeah, by doing more broad. Yeah, for sure, on the server side.

Massive Lightning: Yeah, yeah, um, and final thing might be like user deletion, like, and then it's like a whole like privacy and legality.

General Centurion: Yeah, a good call. Yeah, for sure, that it should be well done for sure.

Massive Lightning: So like obviously there's like GDPR, um, and, uh, like how do you, you know, like how do you enforce like, uh, you know, user Obviously you always have the client as a goalie, but depending on the regulations you might want to have jobs that go and clean up stale, dead users. That creates its own data consistency issues. And then, yeah, I mean, obviously we have to consider security and safety. Like, what if there's stalkers? Mmm, yeah.

General Centurion: Yep, yep. And so they might need tool— you'll need tooling for support or like someone to be able to track stuff.

Massive Lightning: Yeah, yeah, yeah, yeah. And then like, but you know, I think in most product organizations it's usually dictated by like what you know, sort of what the customer wants. So then it's like all the idiosyncrasies of like that, you know, community, I think, is then just kind of like have to like iterate on that.

General Centurion: Great. Okay. Now this is good. Okay. Let's call that the interview. This is interesting. No, very, very impressive that you covered a lot of it, honestly. So you were moving at a good pace. Okay. Do you have any— what questions do you have for me?

Massive Lightning: Uh, yeah, I mean, I guess, um, where, uh, where were the strengths and weaknesses? I would say, oh, for sure.

General Centurion: Yeah. Um, strengths, really strong product sense. I got, um, you like, uh, just got a feel for the question. Um, you identified that like, uh, and like engineering as well, like just, uh, like you identified that like the nearby endpoint is the heavy slash interesting endpoint of this. Good, quick API design. The weak— on the weaker side was definitely on the database schema. And like, you're like, when I asked for an example query, so it definitely feels like you don't write SQL very much. Yeah, which is fine, but I would recommend freshening up, you know. And then when you describe— with any time you describe a schema, you should describe the indexes as well, pretty much, right? Yeah. And then there's also like compound indexes, which aren't as relevant for this problem, but is definitely something to know. There's just like a lot of things with indexes that, um, but like, cause you can index on two columns at once. Um, and so yeah, things like that. Um, but let's think. So yeah, on the database side, um, such a breadth of knowledge, a very good breadth of knowledge. Uh, I was very impressed with your, like, so I guess your knowledge of databases is great. Like the fact that you know that Postgres, that's very impressive. Puts you in like top 10% of people that do this interview question. Um, uh, and just makes you much more likely to finish it because you're not reinventing the wheel. Um, and yeah, you're, you're, you're like, you know, you have a good breadth of knowledge there, but you lacked depth in database. Right. And so, yeah. Uh, cause then when I, like, when I was pushing you, I was like, ah, you know, it was pretty clear that you had, uh, Depth-wise is not your strong suit on it. And we didn't get into any internals on like, yeah, any specific things there. And then caching, if you had like with more time, I think it's nice to dive into what your specific caching keys look like and what the, like, yeah, like the, like people usually use Redis and like, you just see questions like, well, what is your Redis key? Right. Yeah. That's, and that then has an interesting discussion about like, like trying to make like increasing your hit rate and like how to invalidate and stuff like that. Um, so overall I'd say, but yeah, very good breadth here. I think it would just be nice to have a few areas that you can go deeper on for depth. Um, and it doesn't, with interviews, it doesn't actually matter what it is that much. Well, there's two things. One is if your interviewer has depth. So if you, you might guess that for me, I'm more of a databases guy. So I'd push on that. Um, and so interviewers will always have something they're more familiar with and will test your knowledge in various ways, um, trying to figure out how deep you are in their area. And it's fine if you're not that deep in it because like, what's the, you know, like often there'll be mismatches necessarily, but then you also wanna demonstrate your own knowledge in other ways, right? Um, your own depth, whatever that may be. Um, and so, which, I mean, you definitely did with your, like certain random things here, but not as much in the specific technical depth here. I guess, yeah. What would you say you feel like is your best thing there?

Massive Lightning: Yeah. I mean, yeah, I mean, I haven't, I haven't used databases directly in a couple of years. So, you know, I think like, you know, having sort of been the founder, it was like more like, okay, you're kind of responsible for everything. Like nothing can be broken. Yeah. Yeah. Broken. You know, what's funny is like I do remember compound indices now and like I'm sure that if I like took 10 minutes like, you know, a day, I could refresh them equal. So, and this is just something that like I should just know and it was a good call out. Like I think I just need to spend like a day with the Redis documentation and like a day with, you know, the Postgres and perhaps some—

General Centurion: Yeah, I think you're right. Right. Yeah. Yeah. Then you're freshening up. It's good knowledge to learn, right? Cause it's like everyone uses them for almost everything. And even if it could be like an hour spread, like, you know, 1 hour watching some random YouTube videos, trainings and things and documentation spread it like 1 hour, 5 times and you'd be amazing, you know? And so with some hands-on experience as well. No, totally. Cause with these kinds of things you're trying to show, it's really testing, like, have you seen these things before? Or have you like interacted and like, Like what— and you're also trying to figure out what kind of like— has someone done real-time— not what you call it— handled production in like art? Have they ran things in production? Have they, you know, do they have war stories, you know, kind of thing, you know? And so a lot of these like things that you do, like the, you know, your stand, your backup thing, like the thing you mentioned there, and like, you know, it's that— that was like shows that like, you know, you have— you've thought, you know, you're good critical thinking about like you know, what could go wrong, right? And so, but yeah, the systems designers are eventually kind of a quirky thing in general because mostly you're just testing for it. Have people, what, how much have people done, you know, and you do it via designing. But overall, no, I'd say you're extremely well positioned. I think with a little bit of freshening up and then also just practice. I think I, you're the first person to really just describe it with arrows and things in the text. And, and you were going pretty well with it, so I didn't, I didn't push you towards the whiteboard, but I see now that I probably should have, um, uh, just for clarity of design. Um, yeah, yeah, yeah.

Massive Lightning: And I think like it reaches a certain point where it's like the, like the ASCII sort of no longer works.

General Centurion: So yeah, no, but great, great initially. And then, but yeah, just kind of got away. Uh, but no, we have any other questions?

Massive Lightning: Uh, yeah, yeah, yeah, I mean, I guess like, uh, like I'm sort of shooting for like senior, uh, at all, uh, right now. I mean, do you think this is like borderline?

General Centurion: Oh, you're, you're, you'd be— yeah, you're very— this is very well good for senior. Um, yeah, no, I'd say— oh yeah, I mean, honestly, just, uh, juniors wouldn't even get a system design in their year, to be honest. So, uh, yeah, this is like— yeah, that's This is, and then this is, this is a good performance of just senior. No. And so, and you, with your founder knowledge especially too, right? Like you have clear, good sense there. But, but wait, so senior of just like an IC engineer.

Massive Lightning: Yeah. Yeah. I mean, I would probably be like shooting for like, you know, big tech or like a lab position. I think labs tend to generally like downlevel. So it's like, oh, do I need to be like, Shooting for a staff or like, you might need, uh, honestly.

General Centurion: Well, and you have like over 8+ years of experience. Yeah. Yeah. Yeah. Tell people you want staff except senior is what I would say. Um, you should, it looks bad. You should, uh, cause with that much you, you, you're really more aligned with staff level.

Massive Lightning: Oh man. That's terrifying.

General Centurion: But no, but you're, and that's fine. No, no, no. No, I think— no, this is— and honestly, this is borderline staff level. The thing that, like, I mean, the thing that someone might throw a wrench that they'd throw into you, but like system design at staff level would be like multi-region and things like that. But honestly, most places won't even do that. So, um, uh, so, but no, I'd say I would position yourself as shooting for staff, but then just take it then. But, but, and you, but you'd take a senior, right? Um, yeah, a good senior role. Um, that's what I did last time I was doing it and that it worked out pretty well. Let me think otherwise. Oh, and then let's see. Yeah, so strong IC and then like pretty backend focused or like what kind of like AI or like, I don't know.

Massive Lightning: Yeah. I mean, I would probably be shooting for like some sort of like FTE role cuz like that, I think that's where like the founder experience, like I've done full stack for my entire career, but like I can do front and back in my, the last 2 years or the last year and a half. At the chip start, there's not really that much front end to do.

General Centurion: So, um, yeah, and it's getting less though.

Massive Lightning: Yeah. So yeah, I mean, I feel like, you know, we— I mean, I feel like, uh, over time, like, both get pretty commoditized with AI.

General Centurion: So hard to— no, I would agree. No, that makes sense. Okay. No, I'd say you're pretty— based on this, it seems like you've got a good backend, uh, breadth of experience. Um, there— oh, one other callout I'd say is there's a book called, uh, Designing Data-Intensive Applications is very good. Yes. Yes.

Massive Lightning: I've only read like maybe, yeah.

General Centurion: Oh, I'd skim through it. It's kind of long. And so, but you could find, oh, actually honestly, you're, you're, you kind of have a lot of the principles of it already. So for you, I'd say actually more would be specific technology would be more relevant than that book actually.

Massive Lightning: Right. Got it. Got it. Yeah. So like obviously people on Reddit are the heavy lifters here.

General Centurion: Yeah. Yeah, no, I think I was just thinking that cause I'm like overall, yeah, you're, you're, you're using the principles of that book quite well. And so, but just a little lacking in details, right?

Massive Lightning: Yeah.

General Centurion: In how you'd actually apply it and reading that, reading more of that book. I mean, it's still good. I would still definitely put some time in, but more, yeah. Having specific details of how you, how to do things like the whole cron thing, right? Like, uh, what, what you can take for granted about like the TTL in a database or things like that. Yeah. Yeah. Okay. That makes sense. And then what, how much longer, how much longer are you practicing or like trying to, when you, what's your timeline?

Massive Lightning: Well, I'm on, have paid leave for like 5 months, so like I just have like no excuse not to like just nail everything. Congrats. That's great. Yeah. Yeah. I mean, I, I mean, my coding's a little rusty cuz it's like I've just been working with agents. For like the past like month or two. Um, so that's, uh, you know, like I, I struggle now because it's like, you know, you, you can just like do [REDACTED], but like that doesn't really, you know, like I feel like the, that format's like changing.

General Centurion: Um, yes, but no. So here's my recommendation there is [REDACTED] will prepare you for practical interviews as well. Um, okay. Because being a well-versed coder is being a well-versed coder, right? Like [REDACTED] is stupid, but it's just like other traditional questions are like the [REDACTED] skills apply, you know, it's just like, it's just less trivia quest, like trivia-centric, right? Yeah. And so I, but what I would say is from the interviews I've given, a lot of practical interviews as well, and people that are good at [REDACTED] will also do well at the practical. People that can't do [REDACTED] will also not do well at practical, right? It's like It's necessary but not sufficient in that way. All right. Very sufficient but not necessary. Like you don't need to be good at [REDACTED] nowadays as much, right? But being good is still useful. And so it— but like focus more on the medium. Don't like— [REDACTED] hards are stupid, I would say. Got it.

Massive Lightning: Right.

General Centurion: Because no, it's just, it's unless you're trying to do a trading role at like a big, you know, one of those big trading companies. Cause they, they'll ask silly questions. But other than that, I, I would not put too much effort into the trivia things. Yeah. Got it. Okay. But you're in a great position. 5 months. Yeah. No. So yeah, just keep doing like an assortment of things. Yeah. It's great. You're already thinking about system design and if you're already doing on the coding side, no, you're, you're, you're, you're well set up. So just keep on going. Yeah. All right.

Massive Lightning: Yeah, well, thanks for taking the time out, Rob. Really, really appreciate it.

General Centurion: Happy to do it. Good luck with the rest of your next 7 months. Keep practicing. Yeah, yeah. Thank you.

Massive Lightning: Take care. All right, bye.