Frontend System Design Interview Walkthrough: Build the Instagram Feed

So today we're going through a system design interview uh we're going to build a Instagram feed feature with a focus on the front end this is one of the most common system design interviews that you will encounter as a frontend or full stack developer we will also share with you the five most common mistakes developers make in system design interviews and a four-steps framework that you can use to solve any system design interview problem front end or backend bton are you ready yes let's go okay well I sent you a link with the instructions can you pull that up yeah okay so that's our task uh we are going

to design uh to S to go to the system design of the this social media feed now um I do want you to focus exclusively on the feed okay so forget about comments and likes do you have any questions uh my first question would be are we focusing on the mobile app or the web app use case so for this time we are focusing on the web side of the app then let's get started I guess the first thing would be to actually understand who's going to use this and what are the features we need from what I see we going to see different posts I see there are images do we also have video included in this feature we might have

video but for now let's leave it out just assume images um image post with a bit of description some descriptions just like you see it in the image okay perfect so we have some image post there might be some text component perfect and about the likes and the comments and all the share buttons do I need to care about all these too okay so the buttons slash likes slash comments out of scope uh that simplifies things a lot perfect okay let me think so I'm I'm assuming the users will be scrolling a lot uh they also create they can also create posts what how many users do we think we will we will have on this application I

mean you could assume 1 million daily active users 1 million um and just for the sake of the use case let's let's suppose each user will create around one Daily Post okay one Daily Post per user that's what they create but I guess they also scroll how much time they spend usually how many post they consume yeah I assume they will consume around 100 post okay is there any pattern um to when they log in is there any um seasonality like are they more active in the evenings is there any Peak traffic yes so you have two traffic moments pick time around 1:00 p.m. at lunch time and um let's say 9:00 p.m. in the evening

when people actually scroll and what what's a peck time for us it will be around 70% of the users are active at the same time okay we're going to have to take that into account where we talk about scaleability okay so we focused on the functionality of the scrolling part not necessarily the taking a picture creating it creating the thumbnails and all this different versions of this picture I I'll focus a lot on the uh on the scroll part is that right um as you can see Bon is now in the middle of the first step of this system design interview framework quick note as you can see bden already started with the

first step of this system design interview framework which is requirements analysis right going from ambiguous requirements like the you know he's presented with a with an interface to concrete system specifications now before he Dives farther into that let's talk about the number one mistake developers made system design interviews which is to assume too much and don't spend enough time clarifying requirements remember you are being judged not by the answers you give but on the questions you ask especially in the beginning of the interview okay so we have our social media feed we're going to have image post do we have any

information about the size of the image yeah let's suppose on average uh one megabyte okay so that's a 1 Megabyte image we're not going to talk about the buttons and the likes and comments we have a million daily active users but there's an asymmetry on consuming versus creating post I would just call this the read to write ratio read SLR and we will use this later on in the design we'll have a lot more reads from our post service or whatever we'll deliver this post than actually writing and most users are online 9:00 p.m. in the evening so 70% active of the 1 million daily active users that's around 7

100,000 going I add it here 700,000 Peck time okay now if they are active at 9:00 p.m. in the evening 700,000 of them um and they consume around 100 posts that means we will read the post 100 times 700,000 well those are big numbers over the span of What U I mean when you say 9:00 p.m. I'm assuming maybe a 2hour window around 9:00 p.m. so 8 to 10 so this is basic basically roughly and these are very rough numbers but it would be this divided by how many seconds we have in 2 hours so basically we have 2 hours by 60 Minutes multiplied by 60 seconds so whatever the result of this is would be the kind of request per second let's

call it APS which is request per second what I'm trying to get here is how much load we will have on our service so I would say this maximum load given our usage this is what we can expect in terms of system specifications um the other thing is the data throughput so we have a one megab image they are downloading a 100 of those over two hours or however they spend scrolling so we'll also have a throughput capability or Capac capacity problem I we can we can maybe talk about that later again but I'm going to add here like we have a throughput issue most of those we can solve with cloud services I will try and

sketch a first version of the system that we need to satisfy this kind of functional requirements sounds good so as Bon mentioned now that the requirements are clear he's going to move on to the second step of the system design framework which is building what we call the minimum variable system basically putting together the minimum number of parts to satisfy those requirements which brings me to another mistake developers making system design interviews that is not getting enough Buy in from the interviewer they forget that the main goal of the system design interview it's not solving the problem

but showing the interview how you think about the problem and making them part of the process how can you do that ask questions which is what Bon will be doing constantly during the next section okay so I'm going to go ahead and just draft the first version of what we would need here and for the sake of this first iteration let's say I would not care too much about those numbers and the scalability part let's just get it off the ground so m the first thing we need would probably be a web app because our users would need to find us so we'll have some sort of an web app that has the whole scrolling component so we

definitely need some sort of a back end that contains I'm going to call this the feed service that contains our um data about the feed basically the image the title and the description but of course we might not want to store the image directly here it's just a lot easier to maybe have it somewhere here I'm going to call this like an image blob storage which is one of those very simple cloud services to store images as we see there's so many of those that we need something very scalable even for a first version we need a huge place to store all these thousands of images terabytes and terabytes of image data and what

will happen is that the fit service will persist images over there and then the web app will consume because the fit service will send back like the URL of that image um we need the database too so I'm just going to add another Square for database to store kind of the post metadata when when it was created and the description all those kind of things I feel like a non-sql database should do much more scalable for the future use cases and we didn't need so many relationships for now is there anything else that we need let me double check our requirements yes probably this would be it for the minimum kind of the

minimum architecture okay before we proceed one key mistake that you want to void at this stage it's running out of things to say just like B you need to be proactive and this is not easy because at the same time you don't want to become controlling how do you do that well you drive the conversation forward without forcing it you can do this by using open-ended questions like for example hey is there any specific part of the system you want me to focus on okay now back to Bon perfect so now that we have our minimal architecture I'm just going to go ahead and try to to see how would we scale this and for that let

me just bring this number up let me run this through my calculator I can use a calculator right yes you can okay so my calculator tells me this around 10K request per seconds so I'm going to add that number here so we have 10K RPS over here um do we have any data on geography not yet so this data would it be Europe the US let's assume the US and let's assume most of our users are based around in City is where there's more population density okay because of course 9:00 p.m. would be different from the east coast to the West Coast but I would assume let's assume this is the East Coast we have this kind of 10,000

request per second um I'm going to start scaling from the client towards towards the back end so on the client side would probably the best thing would be to add a CDN for the application itself so I'm going to put it here a CDN it's a Content delivery Network that will basically distribute our static asset close to the users so all our JavaScript and CSS which will make it a lot more scalable it also introduced there's no unique point of failure because the application is distributed so it also helps us with not only scalability but availability too so as you can see now that the minimum viable system it's done

we will move on to step number three which is what Bon was getting into that is scaling the system that he just outlined so Bon back to you how can we go about scaling this application you already mentioned the CDN yes so I'll probably add the CDN for CDN content Network CDN for our web app and then probably another one for the image storage so this will go like this right that would be our first um our first change and so that would mean that at least the image the static part okay I'm playing around with these Arrow let me finish this perfect so we have now um two content delivery Networks they

manage our static assets the the read now it's super scalable but what would happen is there's a lot of pressure on our feed service and the database the web app we don't have a scalability problem because it runs in the browser of each user so as long as it's performant and well optimized maybe we can talk about that at the end we should be fine now I would expect a lot of pressure on the feed service and this is when things get interesting I think I mention before this read to write ratio I will just put it here we have a one to 100 read to write and we can use this to simplify a bit the way we scale it one

of the easiest things to do would be to separate this fed service so we would have a read fed service and we would have a right fed service and this would leave independently and what that will allow us to do is to scale very quickly so what do I mean by that we're going to have our right service and then we're going to to have our read feed service this one will take a lot of load and this is why why we will probably end up having sort of a load balancer uh which is a component that will distribute the traffic to a fleet of instances which will allow us to scale horizontally this read Service which again takes most of

the pressure so let me just draw a couple of instances here and this is how our final architecture for this part will look like uh let me just we'll talk about the database in a sec but is it clear so far yes it's clear so you separated the the the read from right functionality so you're able to scale them independently another mistake that developers make at this point of the interview it's talking about things they don't know they try to be proactive and to move the conversation forward but they risk moving into things they don't know about like if you're a frontend developer database scalability it's something

you're not probably pre efficient at if you want to talk about the scalability of the system as a whole you want to keep the conversation focused on the parts that you know best and if you're a front developer everything that happens in the client everything that happens between the server and a client and maybe a bit of server side and this is exactly what Bon has been doing he started talking about scalability in the web app first now back to Bon and back to the read and right service perfect so the last button like here would be our database which still receives a lot of pressure with the requirements we have

so far we could probably go for a nosql database here can you tell me a bit more about this Choice why no SQL so the reason behind this is because no SQL gives us the scalability out of the box kind of Advantage it's a lot more scalable than the SQL kind of structure databases um especially if we go for a document database for example like but at the same time we do not really have a lot of relational data here these posts are pretty much related to the user and that's pretty much it so if we had a more complex data structure if we had complex relationships we would probably go for a SQL uh database like

MySQL or pogress but I think given the use case we can go we can um we can get away with a nosql document database yeah so it's not only the scalability factor but also the shape of the data that you are handling that um you need to consider in this decision that's what I wanted to see cool um perfect and this would be pretty much it because nosql with it can scale pretty well like we shouldn't have too many issues here now let me take a second look at the system and see if there's anything else we can do to make sure this will scale pretty well so we have our CDN and we have a right service that will create

the images there might be some asynchronous work here I didn't ask about creating thumbnails optimizing the images before we persist them maybe we can do that as synchronously with something like a sess Lambda the cool thing about that kind of jobs is that they can be as synchronous so they scale pretty well um and probably the one thing missing would be we could also leverage caching for the read service so I would assume we could probably place a cache or red base cach here let me just pain it in and so because I imagine post do not change um that often uh I didn't ask that in the requirements but I would

assume um people don't change their post where we don't give Instagram doesn't really give the ability to change too much and we can leverage that to really cat this for example you could catch the viral post because we know that everybody will request those ones and we can have them we can have the metadata about them like the the post description and on in a in a red is cache or sort of a very high performance cach memory and that would make things even faster when we read posts okay now really quick another mistake that we see developers making here it's being to implementation focused as you see bden was able to keep

the conversation high level but at the same time zoom in and zoom out and not get too bed down by the implementation details and this is what developers do they miss the big picture like they start focusing way too much into a single component that they know and they get lost in the implementation details and give the impression of a junior Dev split your focus between all components of the system as much as you can and you will do much better than getting bugged by implementation detail and coming across again as a not experienced developer um now that we are almost over over with the scalability of the system

bden is going to move on to the last piece of the puzzle which is scaling individual components okay ban so great job we have kind of the full picture we have the full system now let's focus a bit on the web app and when we are looking at the web app right we will have a few hundred Paws being rendered at the same time in this web app do you see any performance issues that might arise in that case so let's take a look at this one component are we using any component for framework do I need to take that into account is it a free choice yeah so to keep it short we will use react in this case so don't uh don't

spend too much time on why we use react it's one of the most common used and um we can have that discussion either way but for now just assume we are using react okay so I would assume that this is our viewport in the mobile device and we start scrolling so we'll end up having all those elements mounted which are post let me see if I can visualize this somehow okay so we have one of them and I'm scrolling down and I see this ones at the moment but then I'll keep scrolling and have all those elements here I guess one of the big problems will come because we have a Dom and a virtual Dom that will be uh too

big and I think the the browser even has a limit on how many elements you can add to to the Dom but it will become very heavy especially if they are using a mobile browser this will be very heavy so I guess one of the things we could do is to unmount the posts that are not visible outside viewport so this ones for example we would just unmount them we keep the reference but they are not referen anymore and I think what some companies do I think Facebook will render an MTD here with a hidden uh sort of a hidden um property the repaint of the browser do not take those into account but they still are calculated in

the scroll so it doesn't the fact that we move something out doesn't affect the scroll lines um and uh if I recall well there is a package they built for this which is called virtualized list so we need something like this we need a way to remove and add elements to sort of this sliding window like as the user Scrolls we just render the ones the next ones they will see either up or down okay Bon so I understand that's how you would go about rendering this post but what about fetching them um sure so when it comes to fetching those I guess the first idea that came to my mind was having some sort of a pagination pagination so

basically we would have a page let's say page equal to five and then whenever they scroll down we show a loading indicator or we prefetch the next five I'm assuming if my friends for example publish new post then the page the content of page five might change all the time so I might go imagine I'm on page five and I go to page six but there were some posts published I'll probably see some post on page five in page six because they get they get pushed down to the to the next page so I guess it's probably better to do a csor based pagination I'm going to add here csor based pagination here linked with

something like intersection Observer um I use this API before but we basically the quizer would be the ID of one of those posts and we just instruct to render you know the next five after this one and so when people scroll we just change that one csor and the advantage there if is if we get new post added here um it doesn't really matter we didn't change we didn't Shake kind of the scroll there's no complex logic that we need to implement here so probably cursor based pagination would be best and use the intersection Observer to vitalize this list and to to basically unmount what is not in the Viewpoint one

fin question about web performance do you think this would be a good use case for serers side rendering a good use case for server side rendering out of the bat my answer would be no because there's so much State on the client and there's so much interactivity that we don't get so many advantages there's not so much to pre-render on the server I would probably we could probably be able to pre-render everything else around the feed but the feed itself sounds like a a very interactive very stay heavy component and I don't see any benefit from trying to render this in the server especially because people will

immediately scroll so you don't get a lot of advantages for just having something pre-rendered but everything else around the uh the feed feature I think we can pre-render yes we can for the sake of this video we will stop here make sure you also check our senior interview questions video As for me and bden we will see you in the next one take care