[0:00]About three years back, I attempted to make a playlist on system design. Now, the problem with those videos was that they required too much editing because they were very high-paced, they had a lot of edits and cuts and animations. And I made about 13 videos and then my editor took off. So that required like a full-time editor, right? And then for the longest time, I was not teaching system design on the internet. Now the thing is, as you know about me, I've built multiple startups in the past, and I've worked on these products from the beginning all the way to when they have scaled. So I've had the privilege of working on systems very deeply, and I have a lot of system design information and knowledge and a lot of notes and a lot of conceptual understanding. And that's something that I wanted to share about three years back, and I've only been gathering more and more such information. So I thought now is a good time to again try to rebuild my playlist on system design. And so that you don't get confused because of the previous playlist, I've hidden the playlist now, but the videos are still available in case you want to watch them. Now, I'm going to completely re-jig everything. I'm not going to follow that script, like that particular order. I'm going to re-jig things and I'm going to teach system design in a very different way now in this playlist. And I'm going to try to attempt to create a long playlist with all the knowledge that I have. So what we're going to do now is we're going to learn system design from the basics all the way to the advanced in this playlist. Now this playlist is actually free content and a prerequisite must-watch for the people who are enrolled in my Algorock cohort. Now the Algorock cohort is for advanced system designers, people who work as architects, system design, and who basically want to take their career to the next level. Because more serious engineering companies that want senior resources, they look and check for system design skills and that's what most of the interview is about. So this is why Algorock, the cohort, is highly relevant for people with at least five years of engineering experience, right? And we have people with all the way up to 25 years of experience in the cohort at the moment. But anyways, more about that later. Let's start with our system design. Now the first few minutes, we're going to set some context about system design so that you have a first principles understanding of system design and then we'll start digging down into each of the concepts. I just want to inform you that I have screens set up on the left and on the right, and I'm going to be looking at these screens from time to time and I'm going to draw things on these screens. And you'll be able to see that on your screen as well. Now, since this is system design, I didn't want to not have a drawing set up, right? And this is the reason I'm telling you about my screen so that you don't get confused why I'm looking to the left or to the right. Now, this playlist will have many, many episodes. The first one, which is this episode, will be slightly longer because we have to do a lot of context setting. All the other episodes will be each dedicated to just one concept. So they'll be slightly shorter. Now the playlist will get long, and some of the videos will be very difficult, but I don't want you to quit in the middle of the playlist. Just keep going, and this is a great investment in your future. In some of the videos, I'll also be talking about things that do not sound important for system design, but trust me, they are quite important to system design, and that's the only reason I'm sharing those. Now, my promise to you is that you will not get this level of detailed system design content in one place. And if you just go through this playlist, you will know more system design than 80% of the senior engineers in the market, and this increases your chances significantly to landing that great next job offer. Now, if you're in the Algorock cohort, this entire playlist is a must-watch because we'll actually be using these concepts in building and designing systems in the cohort. But if you're not in the cohort, and you don't plan on joining the cohort in the near future, you'll still receive a humongous amount of value through this playlist. Now this playlist is completely free. This will transform your life. Just don't quit. Now, even if you get overwhelmed, just keep coming back to this playlist until you finish it. Your career deserves at least this much of an investment. Now, first, let's talk about why system design is important in 2025. Now the thing is, AI is now able to write a lot of the code that senior engineers used to write, right? So now we have AGENTek AI, we have MCP servers, right, which all of these they work together to iterate and reiterate until they get the code right. So I'm sure if you've used cursor, Windsurf, even just Chat GPT, right, you've seen the power of AI for coding. And we're not sure for how long humans will still keep writing code. And it's projected that very soon LLMs will be able to write code that humans do not even understand. And at least that's the current trajectory that we are on. And this is why companies are very confident of glitch-free operations and hence they're firing people at mass scale. Now the good thing for us is that AI is still isn't complete control. Humans are still responsible for ideation, for planning, for designing the architecture and the system design and telling the AI what needs to be built. In other words, the decisions to use rate limiters, load balancers, proxy servers, all of that is still dependent on human beings. So humans are still the designers and architects of systems. And this is going to be true for at least some time. Because if AI starts coming up with original ideas and planning and architecting, then no job on the planet is safe and we can all go back to farming.
[7:11]So for the next few years, until humans are still in control, the best things that humans can do or the most important things that humans will be doing will be architecting and designing systems. And this is the reason why I built the Algorock cohort. It's meant for senior engineers looking to transition into leadership positions. As you've seen yourself, junior roles are declining and they don't have a great future. And companies will continue to keep increasing the salary of senior engineers. And these senior engineers will be moved into leadership positions at an unprecedented rate, and they'll be given AI tools to help them replace the teams of interns and junior engineers that they had to work with. What this also means is that if you're a junior engineer, you need to start thinking like a senior dev or senior engineer from day one. There is no other program that prepares senior staff and principal engineers to move into leadership positions. The Algorock cohort is the only one on the internet. Now, the internet, including YouTube, does not have a lot of content for senior engineers. And the reason for this is that the internet as a whole incentivizes creation of content for junior engineers. So if you create a basic of Python or basic Java, JavaScript video, you're bound to get a million views. But if you make a system design video for advanced system design especially, you will get barely like a hundred views and nobody wants to spend their time getting 100 views. And to teach advanced system design concepts, you need a lot of understanding and fundamental knowledge. And someone with this knowledge will be earning $300 an hour writing code and building systems and not teaching on the internet for free. Long story short, a big EdTech company or a startup that's raised a lot of VC dollars will not be incentivized to solve problems for senior engineers. Because the total addressable market is so tiny compared to what you can do with junior engineers. And this is the problem that I'm trying to solve with the Algorock cohort. Because this problem can only be solved in a very organic, boutique way. Where they're just a small group of people learning together and completing the cohort together and they become a part of a community or a tribe. And they help each other to grow and share job opportunities with each other. And that's what the Algorock cohort is all about. If you plan on joining the Algorock cohort ever, you can just fill the form of the description of any of the videos in this playlist.
[10:37]Now the first few videos are going to be very easy. We'll learn about HTTP, TCP, REST APIs, all the basic core concepts stuff. And later on, we'll move on to understanding and learning more about microservices architecture and more advanced topics. But each of these concepts, they build up on each other. So don't skip any of the concepts. Even if you know the concept, just watch it on 2X or 3X speed, but don't skip it. Please know that this playlist is going to be a distillation of many sleepless nights plus more than a decade of very rich engineering experience for working with Fortune 500 clients and figuring out how to scale systems. Now this doesn't come easy, so make sure you take the time to digest all this information and ensure that this becomes a part of your thinking from now on.
[11:43]So let's try to understand what system design is. So let's say you go to YouTube and you find a video on how to build an e-commerce website in 12 hours. So in 12 hours, you will be building a front-end, right, and a back-end. Back-end will have some APIs that the front-end will consume. The back-end will also be connected to a database, and this is something that you will end up building, right, in about 12, in a 12-hour video. If it was a five-hour video, you would just build the front-end, and if it was a 12-hour video, you'd expect to see the front-end, the back-end, the APIs, you know, all the services written and then a database. Now the problem is, a lot of the junior developers, they watch these videos and they think that this is it. Like if you have to, uh, like if you if you had to build like an e-commerce website, this this is all that it'll require, right? And Amazon probably has just, uh, a front-end and a back-end and a database. That's how Amazon works, or even something like YouTube. YouTube has a front-end, a back-end, and a database. That's, that's how it is. That's what it is. And, uh, the, the thing is, this kind of an architecture can scale for a few hundred users or even a few thousand users, but it does not scale beyond a few thousand users. You start having structural issues in all of this because this is not a good foundation. This is a good project, like an MVP or a POC that just works for a few users to to validate your idea, but this is not like a full-blown company. And if this was, then you wouldn't have, let's say, 100,000 engineers working at Facebook, or 100,000 engineers working at Amazon, or 100,000 engineers working at YouTube, right? You wouldn't have all those engineers. So you need a lot of engineering because just a front-end, back-end and database does not scale. So you actually need a lot more. So what exactly is system design? System design is basically a planning exercise. You're thinking about the scale to which you're going to be building the software for. And then accordingly, think of different components, think of different architecture patterns and, and all of those different things that'll be that'll be required to actually take the system to that scale. So, how does this usually happen? So, what you have is, you have system design, which is the planning exercise that's done before, right? And then what you do is you think of components. You think of components that will go, uh, into this software that you're building, and that's obviously dependent on the scale at which you're building the software at. Once you have this system design, this is then sent over to someone who's going to do the architecture for it, like probably the cloud architecture or the technical architecture. And they're going to drill down deeper into it. They're going to think about the exact technology that's going to be used, uh, for each of the components, uh, at least at the cloud level or even at the tech level, right? And then you're going to think of, uh, the technologies that you'll use at the at the back-end, maybe Golang or or front-end, you know, which is React or NextJS. What, what kind of databases will you use? So you'll have to take all those decisions. And then, uh, it'll probably go to someone who's going to think of the project structure. Like, how is the project going to be structured, right? And then finally, you'll actually start writing the code. So there's a lot of stuff that happens before you start writing the code. Whereas compare compared that with the YouTube video that you just saw, which is, uh, a 12-hour video, and you just start coding directly, like a front-end, back-end, database. But when you're building for scale, you're going through such a long planning exercise. It's system design that's probably done by a CTO or someone at that level, right, like a technology head. And then cloud architects and, uh, technical architects, they take things forward, they think about what, uh, like if, if this guy has said that we'll use, um, uh, load balancer. So this guy's thinking, okay, are we using ELB or what cloud are we using in the first place? AWS or are we going with Azure? Are we going with GCP? And they're thinking about all of these different decisions, right? And then it's going to the guy who's thinking about the technologies, the guy who's thinking about the project, uh, structure and the design patterns and then it's actually going to go to the person who's going to write the code. So there's a whole long process before that. Now you might think that the architect, right, or the guy that built the system design, which was the guy, like the CTO or someone. Once they've done their bit, right? Once they've thought about the software and how the architecture is going to be, that's it. Their job is done, right? And it just goes on through the developers and the engineers, and now they're responsible for just building this thing out. But that's not the case. These guys actually have, uh, a lot more role to play. It's not like they just design the software and then that's it. They relax. It's not like that. They have, uh, a lot of work day in and day out, and that's something that people don't know about, right? And which is that once they've, uh, given you the decision on, like, let's say, we're going to be using an API gateway, okay? And we're going to be using, let's say, the Amazon API Gateway. Something like that. So once you've given you that decision, the engineer might fall into some kind of an issue. He'll say that, oh, this particular API Gateway, I'm not being able to use it in this way. Can you look for some solutions? So now this whole thing goes back to the architect. Now, he's looking for another solution for this. Or it could be as simple as some engineer, uh, you know, not able to integrate a library. A particular library for authentication and that that will go back to, uh, the software architect. Maybe not the, uh, you know, the cloud or the technical architect, but the software architect. And that guy is going to think, he, this guy is just like a very senior engineer and he's going to think about, okay, what, uh, library then can be used? Or should we use a different, um, technology to do build our front-end with? So they have to take decisions, uh, every day, and then they have to do a lot of research. They have to find out, okay, you know, if this technology does not work, then will this be a good fit for our use case? What are the limitations that they have? Right? So they have to find out about all of that. So that's the job of an architect. One more thing you need to be aware of is that software engineering is actually a very, very new field, and a lot of the concepts that come into software engineering have been borrowed from the real world. So probably know how containerization works, right? We have containers and the containers, they run some kind of a software, and those containers are now used to run inside like something like a virtual machine, right? Uh, that's what we use Docker for. Docker is this container. Now, what if I told you that, that this word containerization and this whole process of actually putting things in a container, of sorts, has been taken from the ships, right? Ships, and how containers are placed on them. Now, the whole idea was if we had containers of the same size, it didn't matter and, or it or it just made it easier for us to ship items from one location to another. That's why we used containers, and that's why the logo of Docker actually is a ship and there are, um, or I think it's a whale and then there are these containers on top of that. That's why the logo is from there. So, a lot of the real world, uh, concepts are actually used in software engineering. And similarly, we have pulled in a lot of things from the automobile industry. So, automobile industry in the '80s and '70s, they were doing a lot of innovation. For example, Kanban, right? So that's something that we have taken from the automobile industry. If you want to know about more such techniques, there is this book called The Toyota Way. So you need to, uh, you can check out that book. So they explain what is lean manufacturing and what is Kanban. And from lean manufacturing came in the whole lean startup methodology, which kind of is the precursor to, and and maybe not this directly, but lean is definitely a precursor to CI/CD and DevOps, and the whole way we that we work right now, right? So, this is where, uh, everything is coming from. Like everything is coming from the real world. So, right now, what we'll do is, for the next few minutes, let's explore some real world examples and how they've, we've actually taken them into software engineering. Yeah, so we have, uh, JIT, which is just in time, and Kanban and lean methodology, all of them have been borrowed from the from the automobile engineering. Now, in the part where I draw stuff, I know my handwriting is quite bad, but that's completely all right because I also have slides to show you, right? Like well-designed slides to show you. So, it just kind of balances your attention, right? If I just focus on slides, then it's not that interactive. And if I just focus on drawing, it's not as well structured as a slide. So we'll, we'll do both. Now, uh, containerization is something that we saw, that's why the Docker whale and containers, that's something that you've always seen. You understood that. And then I had a few more examples here, like blue-green deployments are military strategies, right? So that's great something that we know. Now if you don't know how blue-green works, don't worry, that's what we'll cover in this, um, like in one of the videos in the playlist. And then we have real world influence, like more real world influence. For example, version control, right? Now you have Git, and how multiple engineers are able to work together and they're able to contribute to one central software, uh, and they're able to manage the different versions of the softwares. So, have you ever thought about how that came into existence? That's actually been inspired a lot from film and book editing workflows. So this is what film editing workflows look like and they're very complicated, and that's how code editing workflows or version control came into being. Okay? And some more real world concepts. So we have these six concepts that are used massively in system design, and we can see them or observe them very easily in the real world. Okay? Now the people that build real world spaces, systems, buildings are actually great system designers, and system design is all around us, and we just have to notice. So there are these six things, which is scale, failure, replication, recovery, bottlenecks, and parallelization. And let's look at these six things together. So scale, so think about football fields. So public spaces like football fields are designed in terms of number of seats and toilets, number of food stalls and the vending machines based on the number of people expected. So if you had less number of toilets, like let's say probably just one toilet for these thousands of people, that'd be a big problem, right? So you have to think about the number of toilets, think about the number of vending machines, right? Uh, and it all has to be estimated based on the number of people that are expected in the stadium. And if there's more football than planned, this leads to a lot of issues. You've probably faced those issues. So scale is something that's planned for even in public spaces, right? So, so space and scale. We just don't do that in software, right? So it's, uh, for software engineers, it's very easy to think that everything is like, uh, software oriented. But actually, as you can see, right? From the previous few slides that we're taking a lot of reference from the outside world, from mechanical engineering, from civil engineering, from how spaces are designed, from architects probably, and also, right?
[27:26]So, now the next concept is replication. So think of restaurants, right? Restaurants are highly dependent on their chefs. The star chef creates a dish in a special way, and that's what pulls crowds to a restaurant. But the issue is, the chef is a human being, and he can't cook for the entire restaurant. Like, all of the people who are, who are in the restaurant, he can't cook for every single person. So, he can't be, and also he can't be present every single day. He will get sick. So there are multiple chefs, which is replication, and they can do the exact same thing. So we don't have just one star chef, the star chef has actually trained other chefs to to do the to to work like him, right? And they've built repeatable processes, like recipes, like this is the exact number of steps to to, uh, required to build this, uh, you know, omelet or something like that. So we have repeatable and standardized recipes to ensure same taste, texture and consistency no matter who cooks, which leads to happy customers. Now, if you're a customer and you like the pizza of one place, you don't want the taste to change, right? In my case, I like this pizza, Locali's, it's, it's in, uh, it's in Brooklyn, right? So I like that. So, uh, I don't want the taste to change every single time. I want the taste to be same. So, for for the customer to be happy, right, you want to ensure that, uh, everything is repeatable. So restaurants are thinking about replication. They're thinking about repeatable processes. They're thinking about systems to help scale, like if there are more people, how do you ensure that the pizza tastes the same every single time? So to get the same quality. So as software engineers, we just have to take this thinking forward, take references from places like restaurants and also keep our eyes open. We can learn a lot from being in the real world. Now, bottlenecks. Now this is a huge concept in system design because you'll come across this very often. And this is something you have to think of if you're going to appear in a system design interview, you'll probably be thinking about where can the bottlenecks appear. And to do that, you need to understand what bottlenecks are. So to understand about bottlenecks, let's think about parking lots. Now, parking lots have multiple entries. To understand about bottlenecks, let's think about parking lots. So parking lots have multiple entries and multiple exits. But if they have less number of exits, then the exits will end up becoming a bottleneck, or if you have they have less entries or entrances, the entrances will end up becoming a bottleneck, right? So not only do we need to plan for the right number of entries and exits, but also the right width of each entrance and exit. Otherwise, no matter how huge the parking lot is, it won't get optimally utilized. So, if you have a parking lot that can handle 6,000 vehicles but it just have one entrance, that's not going to be, you're not going to be able to utilize the parking lot. So just the scale of the system isn't important. So you can end up creating a system that can scale a lot. That's not important. It's also important to consider bottleneck that may end up reducing the optimal usage of the system in the first place. Now, this is a very important concept. Something you need to remember and we'll actually use this when we actually do a system design practice. Now the next concept is parallelization. So think about gas pipelines. Gas pipelines have a lot of different parallel systems or pipelines working together. So, gas pipelines are not only critical, but also complex systems where there is massive amounts of parallelization required. There are multiple connections to get to each location. So, if even if a particular pipeline fails, there isn't much dependence on it. It doesn't lead to system failure. The location is still easily serviceable by routing the gas via other pipelines, since parallelization is in place. Now, when you think of this, think of also our software. Our software is deployed in different servers in the cloud. If you just had one server, like one backend server, or if you just had one database, then just the failure of that one server or one database will take down the entire software. But if you had multiple databases, multiple servers, then if just one went down, you still have one more that's running, right?
[33:14]So, since, uh, so yeah. So, so the location is still is easily serviceable by adopting the gas via other pipelines. So in this cohort, we will break down advanced concepts like active-active and active-passive deployments to try and reduce failure. It's all inspired from gas pipelines. Then we have fault tolerance, right? So this comes from space-grade systems. Because critical systems can be made inherently fault tolerant by having internal circuitry that's robust, but also arrangement in a specific order and configuration that makes the system highly fault tolerant. So in this case, you know, we, if you have space-grade systems, uh, you can do all of this to make them fault tolerant. And critical software systems, similarly, similar to, similar to space-grade systems, they need to be extremely fault tolerant, right? The system is hard to take down. The system needs to be hard to take down. You shouldn't have just one attack and the entire system is gone. So this is why we use distributed systems, decentralized systems, right? Because they're highly fault tolerant. If you don't know about distributed systems and decentralized systems, don't worry, we'll cover this in this, uh, playlist as well. So they have multiple nodes and even if some of the nodes aren't functioning properly, the system is still difficult to take offline. So even if some of the nodes are working, and some are not working, still the system can completely function and it's still very difficult to take down. So just basic things like having robust monitoring that triggers off alerts that triggers off self-healing scripts, right, is an example of recoverability. Now this is something you must have done, uh, if you work in the cloud, you probably have scripts that that trigger, uh, self-healing mechanism, right? The servers come back up again, or the containers and or the Kubernetes cluster comes back up again. So all of that is an example of recoverability. So medical systems are critical, but they may not be as critical as space-grade systems. So a little bit of fault tolerance can be sacrificed to reduce operational costs, but recoverability can be enhanced further so that systems come back online pretty fast in the case of failure. Now, one thing to note is that companies are looking for leaders that are good with system design, and it's very logical because if you're a leader in a company, you need to have end-to-end understanding of the entire system. A junior dev engineer will have understanding of just a function or a file or a microservice at best. A senior-level engineer will have the understanding of the entire back-end or the cloud engineer will have the understanding of how the cloud has been set up, right? But only the leader will understand what kind of AI models are you using and what kind of configurations you have on the cloud, what do you have at the architecture level for the software? Right? So you need to understand the system from end to end. So companies are looking for people with macro-level view, which basically means an ability to look at problems from a third dimension. Systems thinking, which is the ability to figure out issues that are created when systems interact with each other. Ability to scale. So, how do you make a particular software scale? So like, let's say you are the CTO of a company and you guys went from just a few hundred users all the way to 10,000 users. Now, the architecture that got you here is going to be very different from the architecture that takes you from 10,000 users to a hundred thousand users. And that'll be very different architecture from the software, the architecture that gets you from a hundred thousand users all the way to a million users. And then beyond. So Facebook is like billions of users, right? So you have to keep re-architecting at each stage. So, um, the, the next thing you need is lateral thinking. So multiple different ways to solve a problem. Now, systems thinking and system design is not the same as DSA. So DSA sometimes, you know, uh, there is a right way to solve the problem. But with system design, there are multiple ways to solve the problem, and this is something that really confuses engineers because we're, we're used to structure, we are so used to, uh, you know, coloring things, and staying within the lines and then seeing things in a box, that when you talk about system design, it's it's just like very chaotic at first, right? It takes a lot of time for engineers to get used to it. And then you have end-to-end understanding. So companies want to depend on people that understand the product, architecture and infra from end to end. So what this basically means is that the higher up you go in the technology ladder in terms of a job or a position, the more the system design is going to be important. So what are companies looking for? Or what can you basically build if you want to get good at system design? You want to be great at planning skills. You should be able to think through deep details before implementation. You should have killer pre-emption. You should be able to think of issues and the best way to solve them before they even appear. And you should have experience of working at scale. So either understanding or experience of how systems behave at scale, any of these two things. Right? Now there are two different, uh, types of system designs. One is the high-level system design, the other is low-level system design. We'll focus on both, right? But it's important to understand the difference between the two. Now, LLD is something that engineers can still be very comfortable with. So, let's say you have about five to seven years of experience, you'll be very comfortable with low-level system design, which is basically talking about tech components in depth, right? You're discussing the exact technology to be used, discussing the underlying DSA or data structures and algorithms to be used. You're even doing schema API and JSON design. And this is basically the detailed implementation plan of the system. So you're very comfortable with this. But HLD is what can throw off a lot of engineers, even senior ones, because here you're just talking about the tech components and not about the underlying details or complexities, right? Doesn't involve DSA. You're not doing schema API JSON design, and it's basically the architectural blueprint and it focuses on just interaction of the components, right? We'll do both of these, but I just want to inform you that HLD is something you might struggle with.
[42:15]Just another quick comparison between HLD and LLD. So this is the overview of architecture and components. This is detailed implementation and logic. This just focuses on modules, interactions, deployments, scalability and security. This one is talking more in depth, right, about the implementation of classes, methods, data structures, algorithms, API contracts. The audience for this is stakeholders, architects and product managers. This is like the blueprint that you give to the architects. For this, the audience is the developers and engineers. So that's why, if you're a senior engineer and you have worked with an engineering team, and you already have some experience in explaining to them how to go ahead and in building the product, you'll be comfortable with LLD, right? Because here the audience of the low-level system design would be other engineers or technical leads. What do you give them? You give them architecture diagrams, component interactions and deployment. Here you have to give them database schemas, API specs, sequence diagrams. The abstraction here is high level and conceptual. This is what makes HLD a little bit more complex to understand for people below 10 years of experience. And this is what makes it a little bit more difficult to understand for people with less engineering experience.
[44:11]An example of this would be the microservices architecture, the data flow and cloud deployment. And here it'll be the API requests and response, and the DB table schemas. The kind of level of detail you expect for HLD would be abstract and conceptual, again. Here it'll be precise and implementation specific. Now the challenge is, when you talk about high level and conceptual stuff, a lot of engineers become very uncomfortable, and we'll do that in this playlist. Now you have to understand that there are a lot of topics in system design and this is just the first list, and we will cover quite a lot of them. Now this is the second list of topics of system design, and this is the third list. And I've just put only about 20-30% of the concepts in system design. So what I'm trying to say here is that we can only cover some of these in this playlist. So, even if this playlist goes on till 100 videos, we'll only be able to cover some of these concepts, right? And system design is horizontal knowledge, right? So you have to gather as much knowledge as possible in a lot of different topics, but for some of the topics, you want to go deep. You want to have vertical knowledge, like deep dive into some of the topics. And to get good at system design, you also need domain-driven knowledge. We'll talk about that. You'll have to practice a lot, and you'll need case study based problems. And this is why I built the Algorock cohort because you learn in a group, it's practice oriented, it prepares you for interviews, for building products, and also for what you'll do in the job after you get the job.
[46:34]And this brings us to the end of this video. In the next video, we'll actually start with concepts starting from internet protocols. So I'll see you in the next video.
