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

An Interview with a FAANG engineer

Watch someone solve the photo sharing service 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

Photo Sharing Service

Interview question

Design a photo-sharing service which allows users to: 1. Upload a photo on their profile. 2. See photos uploaded by other users the user follows.

Interview Feedback

Feedback about Frumious Cronut (the interviewee)

Advance this person to the next round?

Yes

How were their technical skills?

4/4

How was their problem solving ability?

4/4

What about their communication ability?

4/4

-- Good: Asked good clarifying questions (User is logged in or anonymous) -- Good: Asked clarifying questions on private vs. public profile visibility -- Good: Asked really good clarifying questions -- about recommended users and suggestions -- Good: Asked good clarifying questions about the photo metadata --Good: Asked about reactions to photos -- Good: Moved into the discussion on non-functional requirements, asked about photo size, the DAU, asked about limits of number of posts users can make per day. -- Good: Asked about read/write ratio for the app -- Good: Asked about consistency and availability tradeoffs -- Good: Asked good question on whether the verification process is manual / automated -- Feedback: Be sure to spend time on the schema design; Added Followers table --Good: Great question about ordering of the comment feed under a photo -- Good: Very clean API design, with response codes, HTTP methods/verbs. Especially really good work going into the detail on the response codes. -- Good: Great call-out on the pagination support.

Feedback about Platinum Lambda (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

Really appreciate the feedback and direction throughout the interview. Interviewer provided clear instruction and proper follow-up throughout the system design process.

Interview Transcript

Platinum Lambda: Do you have an interview coming upcoming in the next few weeks?

Frumious Cronut: Yeah, so actually I've got a interview with Stripe Friday and then second half of that interview Monday where I'll be doing a system design interview then. Cool.

Platinum Lambda: And are you going for a senior level position? Mid level. Which level?

Frumious Cronut: So right now I'm a senior engineer at Eventbrite and then at Stripe, you know, senior or a level lower is kind of what I'm aiming for.

Platinum Lambda: Gotcha.

Frumious Cronut: Okay.

Platinum Lambda: All right, well, I hope this gets you started. I'm going to go ahead and paste the question here and then if you've seen this before, let me know, I can swap it out.

Frumious Cronut: Oh yeah, I've seen that before, but so happy to swap that out. But honestly, I mean, for the sake of practice, happy to kind of go with this and see how well I do. Okay.

Platinum Lambda: All right. All right, well, let's get started. Have a look in the LUTO if you have any questions on it.

Frumious Cronut: Yeah, absolutely. So. So, I mean, the way I've seen this done before is like going through functional requirements, non functional requirements, talking about core entities and like an API design and then getting into like a high level design. So that's the process I'd like to follow, if that sounds good with you.

Platinum Lambda: Yep, that sounds good.

Frumious Cronut: Awesome. Okay, so for functional requirements. Yeah, so we want to upload, we want users to upload photos of their profile and see photos uploaded by other users that a user follows. So user uploaded photos. So the first question there is for these users, is that going to be anonymous or can we assume that like users have authenticated and signed in when they posted the photos?

Platinum Lambda: Let's assume the users have authenticated, signed in.

Frumious Cronut: Okay, cool. And then so uploading a photo on their profile. So that kind of assumes like users have a profile that other users can view.

Platinum Lambda: That's correct.

Frumious Cronut: Cool. Okay, so user profiles, viewing other user profiles. So when we view other user profiles, is that like gated by some mechanism? Can you only view like, you know, do we have like private profiles, public profiles, you can only see user profiles for users that you follow, that sort of thing? Yeah.

Platinum Lambda: So let's assume that you can only see a profile if you click follow on that user and that user accepts the follow request.

Frumious Cronut: Okay. Can only see profiles of users who follow. Okay, so we haven't talked about following yet. So let's Talk about those requirements. So you mentioned accepting a follow request. So it sounds like we want, you know, user A can follow user B or request to follow user B and then user B can accept or deny that request. Is, is that right? Or is it just like you can send a follow and then, you know, it just happens?

Platinum Lambda: No, let's assume that, I think the former bit, when you send a request, the user has to accept the deny.

Frumious Cronut: Okay, follow request, set deny request and that, you know, we need a way to view pending follow requests. Okay, Users can request to follow another user. Users can view pending follow requests and accept deny. Okay, so that's following. That's requesting a follow. We've talked about viewing other user profiles and then so we also want to see photos uploaded by other users. So that kind of sounds just like, you know, a feed of content. So is there particular requirements around that feed? Is it like algorithmic? Is it just most recent? Yeah.

Platinum Lambda: Yes. Essentially when the user brings up their feed, they should see the most recent.

Frumious Cronut: Information, order by most recent. And you know, I know like feeds today, you get like other relevant content, there's ads. I mean, for the sake of this, I'm kind of guessing we want to ignore that.

Platinum Lambda: Are you talking about suggested people?

Frumious Cronut: Yeah, so like you're looking at your photo feed and there are photos from. Not people you follow, but from what we think you might be interested in.

Platinum Lambda: Yeah, we could ignore those. Let's assume that isn't there.

Frumious Cronut: Cool. Okay. And you mentioned recommendations which like reminded me, do we want to be able to recommend user follows?

Platinum Lambda: Yeah, let's do that. Let's assume, you know, let's provide a notification capability where, you know, a user periodically gets suggested up to three suggestions of, hey, you know, are these, you know, let's, let's tailor this way where they might be interested in certain celebrities. Right. That are, you know, in certain domains. And they get prompted with suggestions of following celebrities. Like for example, as an example here is that if they've been following a few basketball players, they might be suggested other basketball players to follow. So something like that limited to celebrities, not regular users.

Frumious Cronut: Okay, so those follow recommendations are only for celebrities. Okay. So I guess we could generalize that to maybe like high profile accounts.

Platinum Lambda: That's right.

Frumious Cronut: Okay, cool. Okay, gotcha. Gotcha. And then so the solid recommendations. So we've also got search. So I'm guessing we also want to be able to search for other users and search for other photos.

Platinum Lambda: That's right.

Frumious Cronut: Okay. Search for other users, search for other.

Platinum Lambda: Well, I think, let me I say search for users because when you search, when you get a user, you bring up the profile, you'll see their photo. So there's no need to search the photo separately.

Frumious Cronut: Okay, cool, cool. Okay. And then when we talk about user uploaded photos, what sorts of data is included in that upload? Like, can you add a caption? Are there like filters, etcetera?

Platinum Lambda: Yeah. The only piece of metadata will be the caption of the photo and the location.

Frumious Cronut: Okay.

Platinum Lambda: Where the photo was taken.

Frumious Cronut: And will other users be able to comment on photos or react to the photo?

Platinum Lambda: Yeah, let's assume right now that for a given photo the photo can be liked and let's actually include that there can be comments on the photo as well.

Frumious Cronut: Okay, cool. Yeah, I'm just kind of thinking about your typical Instagram ish sort of features. We've captured a lot here. I feel like it's a very good starting point. Is there anything else as far as functional requirements goes that should be noted?

Platinum Lambda: No, I think you got it. Good. I think in terms of the end user, client, device, you don't have to worry about that. You can assume that user can access the app from a mobile, mobile device or desktop or anything like that. And you can also assume you don't have to worry about authentication users authenticated to the system.

Frumious Cronut: Okay. Okay, awesome. Yeah. And so like, along with that, I guess we can also assume there's like an authentication service that, that we can integrate with. Yep. Cool. Okay, so when it comes to non functional requirements, are there any limits around, for example, like the photo upload size or anything like that?

Platinum Lambda: Let's assume the limit on photo upload size is 10 megabytes.

Frumious Cronut: Okay. Photo. Okay. And then do we, are there any estimates around like daily active users or stuff like that?

Platinum Lambda: Yeah, let's assume for the Service there are 1 billion daily active users.

Frumious Cronut: 1 billion daily active users. Wow. Popular. And so I mean, kind of the next question I guess is like, are there limits around how many posts they can make a day?

Platinum Lambda: No, there's no limits.

Frumious Cronut: Okay, so sounds like no limits on writes. I'll assume reads is the same. So for, I guess at this point it probably doesn't make sense to get into capacity planning yet, but it would be nice to get an idea of like, you know, in general our users like writing or, you know, viewing photos more often than they're writing, which I feel like makes sense. But is there like a general ratio there? Like users look at 100 photos and for every photo that they post or, you know, something like that?

Platinum Lambda: Yeah, I think read write ratio, you can assume that's about 80, 20, 80% reads. 20% write.

Frumious Cronut: Read write. Okay. Yeah. So when it comes to like consistency and availability, low latency, the things that are sticking out to me right now is that we probably want very high availability around viewing photos, viewing photos. But it doesn't necessarily have to be hyper consistent. It's fine if you know, it takes maybe some amount of time to see the latest photos from users you follow. So I can note that down as like high availability, low consistency for photo viewing. And I guess that would also extend to like commenting and search. But you know, let me know if that's inaccurate and I can adjust.

Platinum Lambda: I think. Yeah, I mean for the app. Yeah. High availability, low latency.

Frumious Cronut: Okay.

Platinum Lambda: You can assume there's eventual consistency.

Frumious Cronut: Okay, cool. Eventually consistent. So thinking more about like kind of the non functional requirements and like aspects where it's important to focus on like latency, consistency, etc. Is there anything else here worth calling out that we, that I should keep in mind?

Platinum Lambda: No, this looks good to me. Yeah.

Frumious Cronut: Okay, cool. So, yeah, so we've got a lot here. I'm kind of, I'll just get into like some of the core entities that we're going to be working with. So we've got users, but we also have an off service, so we might not be interacting with users as much. But I'll note that. So we got users have photos, of course there's comments. What else here? We mentioned celebrities, so can we talk a little bit more about that? It sounds like we have different user types or is that just like an emergent product of our system? Based on how popular an account is.

Platinum Lambda: I would classify that. So you can assume it's a different user type.

Frumious Cronut: Different.

Platinum Lambda: And essentially you could probably think of this user as those users that are verified users.

Frumious Cronut: I see. Okay. Okay, gotcha. Okay, so if we have verified users, then that means like in our functional requirements we need like some way to register and verify a user then as well. Unless, let me know if you've already got like an API for that.

Platinum Lambda: I think you can use a simple metric. We can assume. So essentially if a user has more than 100,000 followers, they automatically become flags. It's simply based on follow account.

Frumious Cronut: Okay, and so when you say automatically flagged, do we need to get anything around like a process that like verifies their ID and who they say are there or like just for the sake of simplicity, like you got 100k followers, you know you're verified?

Platinum Lambda: Yeah, I think for Simplicity. We can assume it's automated.

Frumious Cronut: Cool. Okay.

Platinum Lambda: And they would have handled any manual checks, ID checks in the background. Yeah, that's a great question.

Frumious Cronut: Cool. Okay, so we got verified users, we got our normal plebian users. We have some photos, we have some comments. Okay. I think for the, like, the most part, those are the sort of like, enemies we're dealing with. So, yeah, let's talk about API design. We got a lot of photo requirements, but, you know, our first thing up here is like uploading a photo on your profile. So let's talk about photo upload first. Seems a good place to start for any. So, yeah, let's post to photos.

Platinum Lambda: Well, real quick. Yeah, I'd like you to dig deeper to the schema. Like, I want to see the schema design for each of these entities.

Frumious Cronut: Okay. Yeah. So talking about the sort of data that's associated with each.

Platinum Lambda: Right? Yep.

Frumious Cronut: Yeah, yeah, absolutely. So users will need a user id, we'll need a name. I mean, there's. We could probably dig into, like, do we want to store first name and last name separately or do we just want a name field? I feel like name localization might be kind of tricky, especially and we have 1 billion data active users. So I'm kind of assuming this is like a global application with users all over the place. So I think just like a single name field probably works fine for our purposes.

Platinum Lambda: That's fine.

Frumious Cronut: User ID name. I mean, password. I mean, we've got an authentication service, so I'm going to kind of ignore that. And then users will have followers, and I don't really have that list in our entities, but I think it makes sense to like, represent that separately. Yeah, I feel like there should be more here, but, you know, users are going to have these other things. So for now I think that kind of our user scheme is pretty light, but let me know if there's anything I need to like, flesh out there.

Platinum Lambda: Yeah, I mean, I think user. Yeah, I'm curious how you're designing the followers table.

Frumious Cronut: Okay. Yeah. So, yeah, so with our follows here, we got. Well, so this is like a relationship from one user to another. So like, what's a good. We could call this like a owner user id. Right. And then a two user id. And right now, I mean, it's. It's follow. So I'm wondering if it makes sense to also have a relationship type. And I don't know if, like, I'm over engineering here, like, if we want follow and like follow with notifications, for instance, or I might Be getting ahead of myself. Uh, but I'm gonna.

Platinum Lambda: What is what Follow with notifications.

Frumious Cronut: Yeah, so what I'm thinking like, you know, if a user wants notifications with each time someone they follow posts, maybe we, maybe we keep track of that in a relationship type. But the more I talk about it, the more I think I'm like rambling a little bit and getting ahead of myself. But yeah, so yeah, that's kind of, kind of the vague thought there.

Platinum Lambda: Yeah, I think I, I see where you're going. I think that maybe going a bit too far. But I think I'm wondering also if you could simplify this and maybe say have two fields, one called follower, one is followee. So essentially the person who's followers, you know. Yeah, I think that might be easier.

Frumious Cronut: Yeah. Okay, so we'll go that follower user id. We'll call this followee user user id. And, and then we need a status because you know, we can have pending, we can have accepted and we can have denied because we don't want like a user to send a follow request it get denied and they just like spam this user over and over again. So we'll want to keep track of both of those states. Yeah. Okay, so I think that looks good for follow. Maybe we you know, have a created at and updated at here for you know, logging, debugging, all those sorts of purposes. So unless there's anything else you want to call up there, I'm going to move on over to photos. So of course we'll want a photo id. We're going to have content associated with that photo, namely the caption. So can I have a caption? You also mentioned the location of the photo, so yeah, maybe we can call this like location lat. Location lat. Location long. Okay. And photos. Comments. Yeah, so comments. Oh, sorry, I'm kind of jumping back and forth here a little bit. Comments. Okay. And then when it comes to comments. Okay.

Platinum Lambda: So where, you know there's going to be some data about the photo, like the actual binary blob, all of that. How is that represented? I mean how do we relate a photo ID to the actual thing?

Frumious Cronut: Yeah. Oh my gosh, I can't believe I missed that. Yeah, so I, I think the way I'd like to handle that is for to use like a dedicated document store and our photo can just like point to the URLs. So and in, in that case, you know, we probably want like a raw URL, a thumbnail version and then different sized URLs potentially based on how the user is like looking at the photo. And so I guess the thing I'm thinking about right now is if this is stored in a relational database, like do we just have a JSON blob that's URLs? If it's a NoSQL solution with DynamoDB or something, then it doesn't really matter. We can just throw whatever we want in here. All that said, I think I'm kind of getting ahead of myself. So for the time being, I think I'm just going to note like this URL is an array. It can have a URL that points to the URL of the thing we're looking at and then the URL type, which is, it's not really a type. We're really interested in the resolution. So we want the resolution of that, the image at that URL. I think that's how I want to store that. Yeah, but yeah, let me know if there's kind of any thoughts or questions around that.

Platinum Lambda: I think this makes sense. So it looks like on the back end there will be multiple URLs. Each URL has a resolution. Wait, is it a one to one mapping between URL and resolution?

Frumious Cronut: Well, I guess there could be many resolutions, but yeah, one. One to one.

Platinum Lambda: Okay, okay, got. Okay, so one to one is fine. I think that's okay. So there could be many. Oh, because essentially is what I'm seeing here is that there could be multiple resolutions. That's why there's an array for the same photo.

Frumious Cronut: Right, right. Yeah. So, and right now, like off the top of my head, I'm not sure if this resolution is like thumbnail or, you know, we specify specifically it's like 240 by 240. Right. But you know, that's. That's kind of the gist of where I'm thinking right now.

Platinum Lambda: Yeah, I think that makes sense. I think that makes sense. I think that clarifies.

Frumious Cronut: Cool, awesome. Okay. Yeah, thanks for calling that out. I like blurred right past, like the actual content of the whole thing we're building. So photos, captions, the location. All right, so yeah, we want to comment on these. So probably need some sort of like primary comment id. We want the parent photo id. One thing I didn't touch on in the functional requirements is nested comments. So for instance, like, are all comments going to be like sequentially ordered by most recent underneath a parent photo or, you know, will users be able to like, reply to specific comments and we can have like a nested comment thread?

Platinum Lambda: Yeah, I think you can Assume that essentially the comment order under photo is ordered by most recent. Essentially most recent appears at the top, less recent appears at the bottom.

Frumious Cronut: Okay, solid. And I'm going through the schema. I also in the functional requirements did not cover editing and deleting. It was just like creation and getting. Will folks be able to edit or delete comments and or photos?

Platinum Lambda: Let's assume that that functionality scope for design.

Frumious Cronut: Yeah, I love to hear that. So we got a comment, we got a parent photo. There's the actual comment itself. So we can just like call that our content. The author user ID here. So you know, obviously if it's like a relational database, you know, we got a lot of foreign key relationships here. But yeah, I'm kind of still up in the air about, you know, how that's going to be designed. So I'm going to hold off on that for now. Just kind of note that like there's a potential there. So you got a comment, there's a parent photo, there is the author of the user ID created updated. Yeah, that's basic comment blob of text. So and then when it comes to verified users, I have this as a separate entity. This is honestly probably just a flag on our users because it's an emergent property of how many follows followers they have. And yeah, so I think, you know, sticking that as a flag here, it's, you know, we could, I think like again, let me know if I'm getting ahead of myself. If we wanted a hyper denormalized relational database model, you could make an argument like if you want to know if someone is verified, just look at how many followers they have. But that would be a lot of read potentially. And based on how we actually end up designing this thing, we might just want to stick the verified on there just to make it easier to check that. So for now sticking that as a, as a flag there. So hopefully that, you know, makes sense.

Platinum Lambda: I'll do one slide.

Frumious Cronut: Yeah, cool. Okay. So yeah, does that make sense as far as entities? Anything else you think I've missed or I should dig deeper into?

Platinum Lambda: Okay, so yeah, follow. Looks good.

Frumious Cronut: Photos. Looks good. Comments.

Platinum Lambda: Looks good. Yeah, this looks good. I like it. Yeah, looks good.

Frumious Cronut: Awesome. Okay. Yeah, so let's dig into API design here. Posting a photo. Yeah, I mean I think like the request, right? We want just like multi part file upload. Right. So I, you know, I can't remember the media type for that sort of request off the top of my head, but that's going to be the content of this Request and our response. I mean, I think we can probably just like in the event of a 200, 200 success, just return the photo ID and then to handle. And you know, in, in the background here for post photos. Sorry, kind of jumping back, we can also handle extracting metadata of the photo. So if we can extract, you know, the location of the photo and any other information we might need. I know on like photos you, you get a bunch of info about like, I think like the camera type and all this other stuff which you haven't really captured in our schema. But, you know, if that's something we care about, we could do that there.

Platinum Lambda: Yeah, good question. Is the caption. Where is that, Is that part of the multipart file? Yeah, yeah, good question.

Frumious Cronut: So, I mean, I think for the caption, mentally I kind of have this user experience in mind where like first you upload your photo and it's probably going to take a while to parse and handle that whole thing in the background, some asynchronous task. So on the next screen, I imagine the user can then enter additional information. So if they want to themselves state what the location is actually or what, what the caption should be for the photo. So, so I'd like to make sort of like that metadata, a separate API request, if that makes sense.

Platinum Lambda: Okay, yeah, sounds good.

Frumious Cronut: Okay, so I'm not in love with metadata, but I'm gonna, I'm gonna go with that for now. So we can set, so the user can set location. Can set. What was I going to say? Location, caption, etc. I think initially we stated no filters or anything like that. That would be complicated. So I'm not going to talk about that more. So for this request here, we've got a location that the user can set and a caption. So setting that location itself.

Platinum Lambda: Is probably.

Frumious Cronut: Like a further discussion. But for now let's say our user just maybe there's some sort of geolocation picker and you know, on a map they select that or they just enter a location and then we have a way to extract the lat and long. But I think for the purpose of this endpoint, this request makes sense and we can kind of assume we get the lat and long somehow. And in the event of a 200 response, you know, I don't know if there's a lot we need to return here. So I think probably just like a 204 empty body makes sense. I'm looking at this and I'm also realizing I've just said Photos metadata and we want a path per m here because we want to know what user ID work or what photo up ID we are uploading this information for. Yeah, and we'll probably also want to handle, you know, 403s if you're trying to update metadata for a photo you do are not the author of or if you don't have authorization information provided we, you know, 500 errors for server issues. I didn't call that out up here, but might as well note that as well. I don't think there's really a 403 if you're posting a photo it's just like are you. Are you logged in or not? But okay, so yeah, that should get us like a photo is uploaded and I want to talk about viewing user viewing. Well, okay, so I guess I'm taking a look at time and I see we're at 35 minutes and we're talking about API design. So I want to focus on what's most important because we have a lot of functional requirements and we can't. I don't think I'm moving fast enough to cover all of it. So I'm going to quickly talk about accepting follows and then viewing. Let's just call it a feed because I think that's more interesting than viewing an individual photo or user profile photos. So I'm going to try to get through that next. But let me know if you think there's something else that's more important that you'd like for us to discuss.

Platinum Lambda: Oh, I think that's cool.

Frumious Cronut: Okay. Yeah. So for following I think we can just call that a post request to user ID follow. I mean really this operation feed impotent so maybe put it makes sense. And this will be to request a follow.

Platinum Lambda: We the request.

Frumious Cronut: I think honestly we don't, we don't need a request here because we should be able to pull the follower from auth headers and response. I mean I think it's like that 204 pattern again. Yeah. Okay. And then so accepting a user request and denying again, you know, item potent operations. If you accept an accepted request it should be fine. So here's the question. I think we're accepting a specific request so it's really a follow ID that we're interested in. And it's kind of an enum here of like accept or deny I think is the way I'd like to structure that. But I'm introducing the concept of a follow ID to operate on a single follow. So I'm going to Go. I'm jumping back up here to our follow entity and I'm going to add this follow id. So yeah, so here a followee can react to a specific follow request and request. I mean everything we need is here in the path. So again, I think empty body and 204. So that lets us follow, that lets us react to the follow. Users probably need to be able to view follows. So I'm not being very consistent in like plurality or singularity here. So let me be better about that. Okay, so I can get my follows. And yeah, that's interesting because maybe we want to like look at accepted or pending. So there, there might be a better way to design that. But for now I'm going to say, you know, you can look at accepted follows and you can look at pending follows Request again is empty and our response is going to be a list of follows.

Platinum Lambda: So.

Frumious Cronut: Is it fine if I just like kind of notate here? Like we have an array of follows, otherwise I can like specify the exact information that's, that's returned here.

Platinum Lambda: He's already. So this gives a list to the user who's been requested to be followed and they can see all the people basically approve or deny. Right?

Frumious Cronut: Is that correct? Right. So you're able to view like these people follow me and these people have pending follow requests against my user.

Platinum Lambda: I see responses, the follows. Yeah, this makes sense.

Frumious Cronut: Okay, so, you know, one thing we might need to consider is also like pagination here. So you know, you know, we could use like cursor based pagination or just like offset based pagination. I think reasoning about like offset and page size is pretty easy to think about. So I'll throw that in there. But yeah, I mean, certainly a topic of discussion. I know some people have like strong opinions about that. So okay, we've got follows viewing follows. So let's talk next again about viewing a feedback. So we want to be able to view a feed of photos. So this is a feed of photos from users. The currently authenticated user follows. And again, we're like getting this currently authenticated user just from, you know, whatever authentication mechanism we have in place. Presumably something in a header request. You know, empty response is more interesting because we're going to want a list of photos and there's going to be some like calculated properties. Right. For our photo, we probably don't need. I guess it depends how our caption is displayed. If I'm thinking of like an Instagram feed where it's just the thumbnail, we probably just need like the photo ID and whatever little like text we need on top of that photo. So maybe we have this photo ID. We have the ability for all the URLs. So I think here, yeah, I'm going to stick with just returning, you know, a thumbnail URL and different sizes of URLs because I imagine like on a desktop that thumbnail resolution might be larger. So maybe the actual resolution that's displayed is like, you know, URL and you know, maybe there's like a small size resolution and that's what's used on like desktop instead of mobile. Created at URLs. Anything else on the feed that we need for photos? I think it's just like list of photos. We want our photo ID so that if we can click on the photo, we can go view it. So I think that gets us.

Platinum Lambda: I.

Frumious Cronut: Think that gets us where we want to be. We can have our created at there. Because I mean, I think typically like when you return a response, it should, when you, when you parse that response on your client, I mean, I mean this array should all be in order. But I suppose just for to be extra careful, we can include the created at. So yeah, so I know as far as time goes, we're at 43 minutes. Do you want to continue to talk about API design and the other routes and such we have here or do you want to move on into kind of like a high level design or. A high level design?

Platinum Lambda: Yeah, this API design looks good to me. Let's proceed with the high level design.

Frumious Cronut: Cool. Okay, so let's pop into a whiteboard. So I toggle the whiteboard on. Can you see that? All right. Yes. All right, awesome. Yeah. So we've got a client for the sake of like mobile or desktop operates the same. We have a lot of functionality that we want to account for. So I think, you know, we want to pass all these requests through an API gateway so that we can route to the specific service. And how much would you like to discuss networking at this point? Do we want to just kind of talk at a high level? Like this request? It's an API gateway. The API gateway directs it to the correct service. Or do we want to like get into like load balancers or like, you know, in aws. I know it's called cloudfront that you can like do some routing. Yeah. What would you like to do?

Platinum Lambda: Yeah, we can discuss networking better. Let's go to, let's go to use cases address.

Frumious Cronut: Okay, awesome. Um, so first off, let's talk about photo uploading um, so we probably want some sort of dedicated photo service. We will need some way to handle the, the photo database. And, and here, you know, I, I think what we've got is like our photo metadata, photo ID, et cetera. Right. That generate things and the URLs. Because I would like to store the actual, like photos itself in some sort of document store. So. Oops.

Platinum Lambda: Submitted data in the document store.

Frumious Cronut: Right. Oh, sorry, say that again.

Platinum Lambda: Did you mean you want to store the photos? You want to store the photo metadata in the document store?

Frumious Cronut: In the document store. Photo metadata. I'm not sure I entirely understand. Could you elaborate a little?

Platinum Lambda: Yeah, so I'm just trying to. You have a photo db. Is that the. Is this a document store that stores.

Frumious Cronut: Yeah, so I mean, I think we could either go with like, you know, a NoSQL or SQL option. I know sometimes folks will refer to DynamoDB as like a document store since it's just like key value, but for the document store itself, like, you know, we've got the image file by photo metadata here. What I really mean to say is like, we've got the lat long, we've got the caption. I think I worded that properly. Does that clarification make more sense?

Platinum Lambda: Yeah, I think I was just confused because you have PhotoDB, then you have Documents Store. I was wondering which one is actually storing the photos. Are the two databases or one database or.

Frumious Cronut: Gotcha. Okay, yeah, so in my mind we have two separate stores for that. Right. You know, maybe, you know, we could potentially use DynamoDB for this photo database, for just handling like the lat long and the URLs. Right. And then we use S3, that's like fronted by a CDN for actually serving those URLs. But now that you bring it up, I'm not actually sure. I'm sure we can just throw like file blobs into DynamoDB and it could handle it perfectly. But at least in like, past experience, I've always seen the pattern where you keep those files in S3 and then you reference them in your persistent storage.

Platinum Lambda: Okay, okay. So I guess what I take Here is the PhotoDB, some relational database that has the photos. The blob itself is where it will be stored in the document store.

Frumious Cronut: Yeah.

Platinum Lambda: Okay, got it. Yeah, maybe just, yeah, just to make it more clear, just. Yeah, calling out that, you know.

Frumious Cronut: Where.

Platinum Lambda: The blob, like basically document store, parentheses, photo blob that's stored there and the metadata stored there.

Frumious Cronut: Yeah, okay. Yeah, thanks for. Thanks for calling that out kind of gets a little confusing talking about like you know, a photo since it's kind of spread out conceptually between two different stores. So when we drawing these arrows is kind of annoying. So when we accept a request for a photo, the way I'd like to handle that is we immediately update our photo database with the information that we have available and then we set up a queue to handle photo processing because we'll accept a raw photo of like 10 megabytes in size, of up to 10 megabytes in size. We don't want to serve that to the user every single time. We want to be able to down res that. So I'd like for the photo service to publish messages to a queue that's basically like, hey, I received a photo, you know, go create smaller resolutions of that photo. So yeah, this photo service, okay, I'm not going to spend too much time on that. And we'll have some kind of worker here subscribed to our queue, picking up messages. Oops. And it will update our document store and update our photo database. So the reason I have photo service saving to the photo database and document store is because the photo service will have our raw initial image. We want to get that in the document store so that when the worker starts picking up messages, you know, it needs the original image to down res. Okay, so that's posting images in, you know, as far as the user experience goes, once photo service is able to properly save to the document store in the photo database, we can return, you know, that photo ID and say like, hey, success. We got, we got your photo. The user will go to the next screen which you know, would be like setting the caption and in the background we'll have this, this async process working. But as far as like saving the caption, if the user has a specific like location that they want to set themselves for where the photo was taken, you know, that would be another request. And the photo service just needs to update our photo database. So high level, I think that's, you know, photo creation and that should cover our, you know, post photos and post photos photo ID metadata requests. So let's talk about like viewing a photo because we will need to serve this information as well. So we've got our document store. The user going to the document store every time will take longer than having, you know, some sort of content distribution network where we have like edge located servers that are caching and serving those images slightly closer to the user. So here we've got, yeah, our document store fronted by A CDN there. Yeah. So I want to do a quick time check. I know we're coming up in like 55 minutes. How much longer would you like to go for? And you know, while leaving some time for like feedback on the end.

Platinum Lambda: Yeah, I think just give it a couple more minutes. I'm gonna let you finish out your thoughts and then we'll stop at 55.

Frumious Cronut: Okay. Yeah, cool. So as, as far as following goes, I mean, I think we're talking just like a pretty simple, you know, crud operation service here that we're, that we're working with. I think there's a deeper conversation we could have as far as when we're serving images, we'll need to check that a user is able to view that image and we'll need to check follows in order to do that. So in order to keep viewing photos low latency, there's probably some optimizations we could do. You know, I think in a typical like microservice framework, our follow service is going to have its own data store. So yeah, there's, there's certainly something we could do there. But yeah, kind of thinking about, you know, what note to finish on. And then as far as a feed, I've seen a couple different ways to handle that where either we have a sort of orchestration service where there's a feed service that's, that's working with both the photo service and follow service to determine what users a user is following and then going to the photo database and checking like let me all fetch all photos for everyone a user follows that, you know, naturally could is probably like a higher latency call. And I've seen some ways to do that where you, you maintain a queue of content for each user and then as photos are published your, your photo services publishing an event to that queue and then that queue is up, you know, added to a user's customized feed. And then you know, you have, you have mechanisms for, for scrolling through that, that feed. But yeah, so I get access.

Platinum Lambda: Yeah, I think, yeah, that makes sense. I'm following you here, so stop to give me some feedback. First of all, I think you did a really, really good job throughout this thing. I mean, I don't even need to see the rest of the design to know that you've given me enough confidence from your upfront assessment of requirements and API design schema to know that I have confidence you can do it. So I think first of all, you did a really good job clarify, asking good, clarifying questions. Right. I think compared to other candidates you do exceedingly well because you really dig deep into the problem. You asked a lot of interesting questions. You asked about reactions to photos. You asked about many different things that have opened up the scope of things. So this is good in terms of a job it shows that you think deep about something. You don't just think at a high level. You did a good move well into non functional requirements discussed. As for the photo size, the data active user count, number of posts user can make sure that you're thinking about the scale of the system you're building. What are the implications? Asking about the read write ratio was good. You asked for consistency and trade offs that obviously you have the queuing system you put in place or low latency. You asked about the verification process, if it's automated or manual. It shows that you're thinking very deeply about the problem and I think folks, you know interview session or and the actual job would appreciate that. Introspection overall very good. I think the only feedback I'd add is the schema design as I prompt you to go into the database schema design otherwise you would go straight to API. But from that schema design you came up, you added the followers information which I didn't see initially added before. So as you go through the interview process, really go into the schema design even if they don't ask you to do it and then go to API shows that you're really being thoughtful and deliberate about the design. And what I was really impressed by was your API design. I think you did a really, really good job. The HTTP REST tool design was very clear. You talked about the response codes, you went into the request and response. It was very coherent and clear to follow. I didn't have much feedback else to add. So really good job there. You discussed pagination and then moving into the system design. You, you know, you, the way you went into it made perfect sense to me. And then yeah, I mean think throughout your communication skills have been. Well you've been pausing in each moment waiting for my approval to proceed. So in my opinion this is a, a performance. I think you'll have no issue in the X interview.

Frumious Cronut: Awesome. Thank you. I've been really nervous about system design because I've the last system design I did I kind of just bombed it. So that's very encouraging. Yeah, absolutely.

Platinum Lambda: The other feedback I had was the document store which is Photodb. So I'd be very when you're doing these block diagrams be very clear.

Frumious Cronut: What.

Platinum Lambda: Data is being stored where. So like when you went to this PhotoDB. Okay. PhotoDB is metadata. It'll store this great blob store. This is storing the photo blob data. So be very clear what data is being stored, where. Otherwise it could lead to confusion. That was the only feedback.

Frumious Cronut: Yeah, yeah, yeah. Thank you for that note. So I have one question about something you mentioned. It felt like I kind of spent half the time just getting through, like, to the end of API design. And I think there's been part of me that's, like, always kind of thought that was bad because you want to get into the meat as soon as you can. But what I'm hearing is that it's, like, good, actually. You want to spend as much time up front digging into and asking lots of questions.

Platinum Lambda: Exactly. I think when you get into an interview, I wouldn't worry too much about getting towards the end and having to knock it out. My sense is that it's important to be very thorough in your requirements analysis design, and that's sufficient enough. So even if you don't get to complete the whole thing, that's fine. You showed you very much thoughtfulness in terms of your articulation, your design, and really, in the real world, the fact that you already have an API design or schema design, anybody could take this and just build it, and it's very clear to follow. So, yeah, I wouldn't worry too much.

Frumious Cronut: Awesome. Great. Well, thank you so much for your time.

Platinum Lambda: Yeah, thank you. Good luck.

Frumious Cronut: All right, thank you. Have a good one. Yep.