# What is a System Design interview ? It is not difficult to explain what a System Design question is, but I would rather give an example of a question I faced in my first job interview. > Have you heard about **Netflix**? Yeah, the one with a capability of streaming hundreds of thousands of videos, serving millions of customers, without little or no buffering. Yeah, the one platform whose ownership is 20.15 billion $, and which has become a verb replacement for "watching movies online". Just explain me how you would build it in 45 mins. Go ahead, and your time starts now. 😎 Please bear in mind I was just out of my engineering college and the toughest questions I have ever encountered were of Data Structures. Anyways, the interview was a dumpster fire, I learnt a very interesting aspect of software engineering, designing scalable systems. In a System Design Interview, you are asked one single question - to design a system. It could be an already available system like a video streaming service like *Netflix*, an e-commerce website like *Amazon*, *Flipkart*, and ride-hailing mobile app like *Uber* or part of scalable system like *Recommendation System*, *Search Engine*, etc. It might sound scary to some people, but it is really enjoyable once you start on the journey. # Example Let us demonstrate a typical interview. A common thing in system-design interview is that they never call the interview "System Design Interview". It would just be a *technical interview*. The interview could start something like this: Interviewer: "Please tell me something about your past work." Candidate: "Blah blah blah….." Interview: "Ohh I see. You have worked on interesting projects. Okay, but tell, Mr./Miss D, if I told you have a design traffic control system. How would you do it ?" That was your cue, and you have 45 minutes to explain it. Simple, isn't it !? Not really, in between your explanation , your interviewer is completely free to counter your proposed model with his/her created caveats, forcing you to alter your model built out of love and care, into something which would in truth be a pure ball of monstrosity. It does not matter whether you like your design or not. What really matters is if you can satiate the interviewer with your design, and concurrently without divulging into unnecessary intrinsic details, complete the design within the specified time-limit. That is how a typical system-design interview is conducted. # What is tested in a System Design Interview ? There are blogs and courses and YouTube videos explaining this. I don't think I need to explain this, but just because I have to make this heading, I will put my thoughts here. I think system-design interview you are tested. Yes, that is right, you as a human being is tested, all puns intended. Do you remember, all services of Google went under somewhere in the beginning of January 2020? Slack experience the same thing too, later that month. Services like these are paramount to businesses and users were getting affected in real-time. I don't work at either of the companies, so I don't know how exactly the resolution process works. But essentially there are **on-call** software engineers who sort of like doctors working in the graveyard shift (ああ、これらの貧しい魂). These are the first responders on the problem and follow certain protocols and try to fix these problems. Anyways my point is, imagine being in that position, with ton of money at stake, immense pressure from the supervisors to fix the problem, probably sleepless, irritated, and still trying to fix a bug which could have been caused by anything, quite literally. (Please look at video from [Clément Mihailescu](https://www.youtube.com/watch?v=GiXOPbI0BmM&t=823s&ab_channel=ClémentMihailescu)) To handle such pressure is not an everyday job of a typical software engineer, but the companies need individuals to work on mission-critical stuff in their businesses, and they need to be able to take sound decisions on their own. According to me, a System Design Interview tests this in a candidate, but what do I know, I am a simple guy, trying to put fit pieces in a puzzle, so feel free to drop your thoughts in the comments section. # How to attempt a System Design Question ? Anyway, moving on. How would you attempt such a question ? ## *1. Scope the Problem* ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/22jkm78zw6l8lglfk1t0.jpg) - **DO NOT make assumptions 🙏 and ask clarifying questions to understand the constraints and use cases.** Never ever say in a system-design interview, phrases like, "Let us assume,", "Considering a situation,", "I presume something,", etc. The problem with these is that you can always be stopped midst your explanation with actual conditions. So, it is better to clarify every stupid doubt you have. I am calling it stupid, because I have felt that there could be some point, you'd think in an interview setting, is that something worth asking, might turn out to be totally worth asking. This happened to be as well. In an interview, I was asked to design something like *Tinder*. I had to talk about implementation of load-balancing for the application. I was hesitant to ask about the requirements to choose the Load Balancing Algorithm, but I was fortunate enough that the interviewer pointed out the requirements before I continued the blabber. That day I learnt another lesson, "Never hesitate to ask questions before you answer anything." And what is the worst that could happen. Well, they would laugh about the fact that you did not know a simple thing and reject you. Nah, that seldom happens. On the contrary, interviewers feel good when the candidate asks them question, and you as a candidate gain two things- bonus for communication and experience on interviews. So, bottom line, first get the most important thing: *REQUIREMENTS CLARIFICATION* - **Define limits for the system 🛑.** With the scoped requirements, set the boundaries for the design. Jot down the constraints and the limitations you are supposed to work on. The constraints could be anything, from network-related specifics to workload size and to deployment specifications. It is like the imaginary limits to our sandbox where we are supposed to build our system. So, the bottom line, the next step here: *SYSTEM INTERFACE DEFINITION* ## *2. Sketch up Abstract Design* ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i18feh5acnjq6yfh6h47.jpg) - **Building blocks of the system and relationships between them.** Now, that we have sufficient grip on the type of question being asked, fixed down the system constraints and boundaries. That would lead to next step of our resolution, *Estimation*. Here is where we can use our assumptions, but always staying under our requirements. This step is crucial as this discussion would decide the type and method scale parameters we might need to consider. But now what would an estimation look like ?? Here's an example, let's consider that we are given to design a system similar to ***URL Shortener***. How would we estimate anything about it ?? More importantly, what do we estimate exactly ?? Unfortunately, there is no golden trick to estimation, but with some practice you can get started on cracking this egg. So, back to the question, we must design a ***URL Shortener***. 1. *What does it do ??* It shortens long URL to a short URL. Duh ! 2. *What input would we need ??* We need `long_url`, `short_url`, `created_at` time. We might want to append an `expiring_at` time as well. 3. *How many users will be using our product ??* In range between `1` and `30` million all over the world. Let us try to estimate our Data Capacity Model: - Estimated Size of Long URL ~ 2 kB (assuming 2048 characters for a long URL) - Estimated Size of Short URL ~ 17 B (assuming 17 characters for a long URL) - Created_At time ~ 7 B (7 characters) - Expiring_At time ~ 7 B (7 characters) All of these totals to 2.031 kB ~ 2 kB > Please do not scream that we should take 3 kB not 2 kB, 😒😐. > I am pretty sure the interviewer cares only about your thought process and not your mathematical skills. Anyways, moving ahead, let's take the upper most bound for our users, 30 million users using our product, each using it for 2 times per day, meaning 100 fresh entries. This means per day we generate 30,000,000 x 2.031 kB = 57.22 GB per day = 1.68 TB per month = 20.11 TB per year = 120 TB per 6 years (not too shabby, if I say so myself). Once, you are done with this, try line out a very High-Level Design of the system. For example, you can just what all do you need to code this system. Discuss your high-level approach, how would you attempt the design. That is it. Continuing my example of ***URL Shortener***, to create it all we need is an encoding algorithm. We could use `base62` encoding, `base62` encoding can result into 10⁷ combinations. ```python def base62_encode(deci): s = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ' hash_str = "" while deci > 0: hash_str = s(deci % 62)+hash_str deci /= 62 return hash_str ``` > You don't have to code the encoding algorithm. I have just put this for the sake of comprehension. Now, all we need to do is to store the encoded entries of `long_url`, but before that the database has to be decided. Which is going to be chosen for storage ? We have 2 choices for DBMS - *RDBMS* and *NoSQL*. As *NoSQL* is **BA**(Basically Available) **S**(Soft-State) **E**(Eventual Consistency), it fulfils our requirement of availability in multiple failures. A simple application of this system could be as follows: ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/37ro3i4auqixducn6ntg.png) So, the bottom line, the next steps here are: *BACK OF ENVELOPE ESTIMATION* > *DEFINING DATA MODEL* > *HIGH LEVEL DESIGN*. ## *3. Identify and address the bottlenecks* ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c12xd5m6igy3loijxjnm.jpg) - **Use fundamental principles of scalable system design**. Next step will be to discuss out our high-level detail for our system. Here, is the place where you would describe all the moving parts which might be required to design this system. You go as in depth and as detailed as you want, but bear in mind, your interviewer might ask you to change a lot of things in your design. Be ready to adapt as you go. No matter, how many wrenches are thrown at you. In addition to this, you must be aware to bottlenecks you would be creating along the path of designing your system. Not only identify your bottlenecks, but you must also be ready to resolve them with alternatives in your knowledge arsenal. Your interviewer will probably guide you if you are communicative enough. There are various problems in the above implementation. One which could be outlined is multiple nodes come up with same random number. A₁ and A₂ could generate the same random number, which would lead to hash collision. ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nwok7a4tw8f2ko0d7fct.png) To overcome this, we could separate out the counting mechanism. ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/iurcvwksh9jk7frxik4y.png) But the problem again is what if that counting mechanism fails, or what if a counter runs out of range. The fix could be using a ***Zookeeper***. ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6ajjbj4k9f5biuhqkvbn.png) The ***Zookeeper*** is responsible for the following: - *Registers the nodes* - *Selects the master* - *Health checks* - *Co-ordinates load distribution* - *Assigns a new range to the counters when it runs-out of range* The final model ought to be something like this: 1. `create_tinyURL(api_dev_key, original_url, custom_alias, user_name, exp-date)` 2. `getLongURL(api_dev_key, url_key)` 3. `getAnalytics()` So, the bottom line, the next steps here are: *DETAILED DESIGN* > *IDENTIFYING AND RESOLVING BOTTLENECKS*. That's it ! You need to complete this within the specified time limit, and you must be good. But to do that, you need have your foundations clear. You need to read blogs, read good books on system design and other resources, and lastly, practice mock interviews on available online platform. Thanks for your patience and reading my mumbo till the end. Please hit the heart ❤ button if you liked the post. Unicorn 🦄 it if you found it valuable enough. Bookmark 🔖 it if you would want to get notified about more blogs of mine. Leave a Comment 📰 if you agree or disagree with something. > **Photo Credits**: > > 1. Photo by Kumiko SHIMIZU on Unsplash. (Cover Image) > 2. Photo by Markus Winkler on Unsplash. (Think Image) > 3. Photo by Hal Gatewood on Unsplash. (Design Image) > **References**: > > 1. [System Design By Gaurav Sen](https://www.youtube.com/playlist?list=PLMCXHnjXnTnvo6alSjVkgxV-VH6EPyvoX) > 2. [shashank88/system_design: Preparation links and resources for system design questions (github.com)](https://github.com/shashank88/system_design)

aditya109

Beginning System Design - Introduction

Join Our Newsletter. No Spam, Only the good stuff.