System Design (TPM) Mock Interview: Twitter API

how would you design twitter's api [Music] hey everyone we're here today to do another system design mock interview these system design interviews will be helpful for you in your upcoming technical program management roles uh we're here today to have jacob do a mock interview with us jacob is exponent's co-founder and cto and today we're going to be asking a system design interview question it's a little more technical in nature that focuses on apis and so the question that i'd like you to ask you today jacob is how would you design twitter's api um and so this is a system design problem so i'd like you to think you know from a very practical standpoint you can use the whiteboard which we'll i think you'll share in a second um to kind of talk through how you'll think about this problem okay awesome all right so um designing twitter's api um this is a good problem uh so how exactly when you say api do you mean um uh the overall api that we would that twitter itself would use um or can you give me a little more detail there yeah so um obviously twitter as a company now has tons of apis for a ton of different purposes um so we want to kind of strip it down to some of the basic functionality that we'd expect from an api such as reading and posting tweets and things like that and we can kind of be a little flexible throughout the interview about what that looks like but it could be something that could be used by twitter's mobile client for example gotcha okay so this this could be the first party api that um the twitter's mobile or maybe web client is like using um and you mentioned reading reading and writing tweets are there any other features that we want to support like um uh getting the the timeline or the followers uh for a user yeah um we definitely want to support both of those um we can leave it a little flexible i leave it up to you to decide what the specific important api uh requirements are uh but definitely at the very least some of the things that you mentioned we have about four so far okay great um yeah i guess yeah let's start with sort of uh sort of like an mvp of this api and what that would look like um i'll start with like tweets uh a timeline and uh followers of a user because those are sort of the fundamental things that make up twitter um but before we jump into kind of like drawing out and sketching out the whiteboard um it'd be helpful just to hear from a high level uh from you about how you're thinking about structuring the api um and any important components that you have before we kind of jump to the whiteboard yeah of course um so yeah an api uh i mean typically it's uh it's going to be sort of served by a web server um and there's a bunch of different sort of uh ways you can structure an api um typically you know it's going to be um we're going to expose sort of endpoints to this api through an api server and there's a few different ways we could do this for sort of one of the most common standard ways is to make what's known as like a rest api where each sort of resource or feature we just talked about will have a specific url that you would um that the client or or the consumer of this api would be using and we can talk about sort of uh the structure of each of those features and the types of data that it expects and returns um because ultimately the api is sort of like a contract between a developer and a consumer so we want to sort of structure an api in a way that's easy to sort of understand and document and things like that got it um and you're mentioning a restful api are there other alternatives that you're considering that you've decided not to move forward with in terms of the structure yeah yeah there are a lot of alternatives um so um it depends on sort of the the context and the kind of service you're trying to make rest apis are sort of they've been around for a long time they're sort of easy to understand and document um the i mean there are other alternatives like soap there's a newer one called graphql which is more developer friendly which is more focused on sort of fetching and reading like graphs of data um but uh rest is has is sort of standard and is great for apis that are potentially across different types of clients that might have different levels of support for these other libraries sort of the lingua franca of like api design awesome cool okay so now that we've sort of uh scoped out what it's going to look like that we're going to go ahead with the restful api design like uh would love to see specifically what some of these apis what some of the api commands will look like yeah totally um yeah for that let's i guess we can go ahead and jump into the white board and i'll sketch them yeah okay i had a few minutes to sort of write out uh what i think our major endpoints would be for this api um and i'll just sort of walk through these and feel free to interrupt me if there are any um any questions or if you spot any problems that i might not have thought of um so uh we mentioned the the features the the sort of resources we wanted to support were tweets so getting and and posting tweets um getting a user's timeline um and then getting uh the followers for a user so i made all of those uh sort of endpoints here so starting with the tweets endpoint um it's uh it's typical in sort of a rest api design here that you would sort of name each endpoint with the resource that it refers to so um so this one is just called uh api tweets um and what we'd like to do is support probably multiple operations on tweets and uh the way i would think about this if i were designing this api is that um we can sort of uh use the http methods of get and post to sort of refer to these different operations we want to do on this resource so uh the most common operations you would want to do are sort of the like the crud operations create read update or delete um for now i've just included the um create and read sort of operations but we could talk later about how we might add in some of those extra features so yeah starting off here i would have a method for getting a list of tweets so if you were to make if the client were to make a get request to this endpoint they would get a list of tweets um so we would probably want to offer a few options here realistically to support like the kinds of applications that twitter uses so we might want to get the tweets for a particular user uh so we could pass a user id param um or we might want to get a particular tweet and sort of maybe the details about that so we could also pass like a tweet id param does that make sense yep that makes sense um great okay and then on sort of on the flip side on this sort of post side this would be the way that uh clients and developers would create a tweet um so we would um it's not written out here but we would want to pass um some sort of object or dictionary of the tweet content so maybe the actual text as well as any sort of media or links to that media and any other sort of details about about the tweet that would be relevant um yeah and then uh in both of these cases as well as in the rest of these endpoints uh we would also uh we would want to return a relevant status to the client based on whether it was successful or not so the standard way of doing that is like you return http 200 to indicate that a request was okay got it can you just walk through one other sample response that this api might give yeah exactly so um there are a bunch of different status codes we uh we would want to support um and that you know these sort of are standard codes that sort of indicate things that went wrong or maybe potential problems with a request so another one could be a 404 if you made a request to an endpoint that doesn't exist or there's also a 403 or 401 if you're missing authentication or you're trying to do something your user or account doesn't have permission to do got it um and feel free to if i don't want to interrupt you if you want to keep going through the api but i'd love to also you know we've listed out this is a great list of an api i'd love for you to also point out one flaw in it or something that's missing here that you would have added if you had more time as well yeah totally um i think yeah the other endpoints are sort of a similar story in terms of how they work um in terms of things that are sort of missing here i think um there are these other sort of operations that i think are probably pretty uh pretty critical to supporting like updating or deleting so those are things i would i would definitely want to support as well um one thing we haven't gotten into is how the authentication would actually work for this api um so i can get into that if that's um yeah i would love for you to just maybe yeah if you can talk a little bit more about how authentication uh plays a role in this api totally so yeah authentication is like an authorization is a super important topic whenever you're talking or about or thinking about an api um and it's important because uh if you know if we're designing twitter's api we want to make sure it's secure and that not anyone can post a tweet from someone else's account or read tweets that are protected maybe um so the way i think about that here and the way that a lot of standard apis work is prior to making a request to the api you would obtain some sort of token like an api token that you send along with your request so the the way this commonly happens for instance in a web browser is you sign in to your account um and then you get a cookie that sort of identifies your user or your session and then that gets included any requests you make in a subsequent um request the api and so we can think about that pretty much in the same way here so we want to make sure that um for any of these requests we want to make sure that our api is designed so that it's checking that the user who's making that request is authorized to perform that operation so in particular here like you would probably not want to allow anyone to post or create a tweet for a particular user or at all if they're not authenticated to do that you also wouldn't want to allow someone to update the followers for an account that they're not logged into um those are just a few examples got it okay that's super helpful um is there anything else that you want to talk about about this api or authentication before i just have one other follow-up question as well that i want to ask about uh rate limiting too um yeah i think like maybe one topic we didn't really get into is how we would actually sort of generate and return the timeline um and that's sort of an interesting one because it would um depending on sort of the way we want um the application to work uh we might need to refresh that we might need to pull that that api endpoint on a regular basis and we also need to sort of support pagination like going through multiple pages of results or loading new results over time um so that that could be a pretty um there's a lot of different ways to do that and i i won't get into like the details of that but basically we need to support um a few different options um to some point to to do that efficiently and to support different different products got it cool um awesome well uh thanks for that thanks for the screen share i think you can close it out now and i just have one last question that i'd love to ask you about um the rate limiting that we might need to put in place uh so often apis especially like twitter's api may be very popular and used a lot so how would we think about uh these third parties that might be using twitter's api um or even our first parties and what rate limiting we should put in place and how do we think about that yeah that's a great point and i i should have mentioned that um but yeah when you're designing anything like this or one that's used as sort of the scale um yeah rate limiting is is definitely a concern um the way i would think about that is uh well there's there's probably maybe two sub-components of that um one is sort of a natural sort of um how do you design an api that is scalable and supports like a lot of users using it for legitimate reasons um and then the second one is maybe like how do you prevent potentially uh uh malevolent uses of the api people who might be trying to ddos you or um or create artificial load um so i think and there's a few ways you can you can handle both of those um there's actually an http status code you can return that indicates that someone is being rate limited so this is something that's really built into a lot of these these apis as well in terms of how we would handle it so one thing we can do is you can actually on sort of a user by user basis we can actually limit your use of the api to a certain time window so you might have a certain number of requests per minute so that's one strategy another thing you could do is you could try to sort of detect um unusual uses of the api so spikes that might indicate that someone's trying to you know do something unusual and then you could sort of temporarily either ban that user or the ip address that those requests are coming from got it okay cool um thanks for answering that uh is there anything else that you want to mention in the interviewer interviewee mode that you're in right now in terms of uh the twitter api design those are all the questions i had um yeah i mean i think there's there's so many features and different things uh we can talk about here um i think we we've covered some of the basic grounds um and yeah this is just one one potential solution to a pretty complex problem got it cool um okay awesome well let's uh pause there in terms of the interview uh of course as always how did how did you think that went for yourself first and then i can share some of the notes that i wrote um yeah i think it uh i think it went pretty well um uh we talked we spent a lot more time uh in this interview talking about sort of the structure and nature of apis and talking more about trade-offs there which i think was good um we didn't talk a lot about sort of the sort of architecture of how you would actually build this so if we were to go longer or in more of a real interview i would i would definitely go there and i would talk about how to actually support and implement these things got it cool yeah overall i thought you did a great job you broke down problems well you visually explained things with the whiteboard which is always an effective tool um you asked good follow-up questions in the beginning to kind of clarify the scope of the problem um and you also in reverse handled those follow-ups pretty effectively um and i thought you had a very structured i thought one thing that excelled in this interview is that you went about it in a very structured way so a lot of times i could hear you kind of breaking down problems into sub components um or even calling that out explicitly or drawing that out explicitly i'm like here are the two approaches here's the approach that i chose we could talk about the other approaches and then you could talk about them if you wanted to um so i thought that created a nice tree for us to sort of go down and talk through the problem for me as an interviewer to really crisply understand what you were saying and then yeah i think you know in terms of things that we could have done if we had more time or would have improved i think yeah talking through the actual architecture would have been helpful we try to keep these short so we didn't get to that as much in this interview we wanted to focus on the api which was uh i think a good use of time um i think you know in general just like checking in with the interviewer is always really helpful so um prodding me it's like hey is this the direction i'm gonna go in or is this direction you want me to go in is always really helpful and and doesn't happen as much in these formats because we're sort of already doing a problem that is a practice problem um but yeah otherwise i thought you did a really great job really great job breaking down the problem and visually explaining kind of your answer clearly any thoughts reactions comments to the stuff that i just mentioned before we close out i know i think uh sounds good cool all right well thanks jacob for uh being willing to be interviewed and uh thanks for doing this system design a mock interview question there are plenty more like this in the course um and to those of you watching good luck on your upcoming interview thanks for watching did you enjoy this video check out more of exponents courses at tryxponent.com to see more courses like our new tpm interview prep course or our software engineering course [Music] you

Channel: Exponent

Views: 50,778

Rating: 4.8265181 out of 5

Keywords:

Id: k-E4YdEs8qM

Length: 19min 0sec (1140 seconds)

Published: Mon Jun 15 2020