Hi everyone.
In today's session, we are going to cover the complete end to end guide to learning system
design. Today's session is going to be one of the most in depth as well as crystal clear sessions on what
exactly do we need to learn in high level design and low level design. Now whenever we talk about
system design, it is a very important concept. Especially if we are targeting SD2 or higher roles. And if
we want to become a CTO and a tech lead in the future. Because in system design we cover many such
important concepts which are very important for designing highly scalable robust systems.
Now what exactly is system design? To understand this, if we talk in basic layman terms, then system
design is designing day to day tech based systems. For example, on a day to day basis we must have
used Netflix, Uber, Instagram, WhatsApp. So in system design interviews we have to design one of
these systems. For example, the interviewer can tell us that you have to design WhatsApp. Now as a
software engineer, there are some basic tools, some basic concepts of which we should have an idea to
design WhatsApp. And we learn these tools and concepts with in system design. And today we will be
discussing in detail about the concepts that we have to learn within it. So we learn system design in two
parts. The first is high level design in which we design the overview of the system. For example, if we
design WhatsApp, then which database will we be using in it? In what way will we use message
queues? In what way can we use cache? So in this way we explain the different components of a
system and design an overall system. Here we do not have to code anything as such. The second part
of system design is low level design. In which we actually have to do machine coding. Where we also
design APIs. Where we also create class diagrams. Where we also describe our models. So here our
actual coding skills are being tested. Today we will be covering the concepts of both HLD and LLD in
detail.
Now there is an important prerequisite before learning system design and that is to actually have
hands on experience and development. If we go and learn system design directly without learning
development, without creating any project, without doing some work at least at SD one level in any
company, then many concepts will seem theoretical to us. We will not be able to understand them
practically. So it is very very crucial that before learning system design, we should have designed some
systems for ourselves at some basic level at least at the project level so that we can relate that when
we are talking about database. When we are talking about cache, what is their actual use in a real life
system. So in the first half of the session we are going to cover HLD and in the second half we are going
to cover LLD.
Now first of all let's talk about high level design. Let's suppose we are sitting in an interview and the
interviewer asks us to design a Netflix like system. Or we have to design Netflix itself. Which means we
have to design a service which is able to serve video content to millions of users across different
countries and that too seamlessly. Now to understand this system better, we will have to understand
two things. Which are functional and non functional requirements. Functional requirements mean
what are the exact features inside the system that we need to build which will actually be used by the
users. For example, for Netflix, users should have the feature that they should be able to register and
log in to the system. Along with that, users should also be able to purchase the subscription of Netflix.
Along with that, whatever users are there, they should be able to play and pause the videos. So these
are all the different features that users will be able to use on Netflix.
Along with this, there will also be some non functional requirements of our system. Non functional
requirements mean how our system will perform. What qualities will it have? For example, if we talk
about Netflix, it should be a secure service. Which means that only paid users should be able to use
the paid content of Netflix. So there should be a proper authentication and authorization setup inside
our system.
Along with that the system should also have low latency. Because if the videos take too much delay
to play then no user will want to watch it.
And thirdly our system should also be scalable so that millions of users can watch the same movie or
the same TV show concurrently. So as soon as we identify all these functional and non functional
requirements for our system, after that we have to design our overall system keeping both of these in
mind. So now we are finally going to talk about what are the components, concepts that we have to
learn step by step inside the high level design to be able to design this Netflix system.
Now the first step in HLD is to learn about some of the fundamentals. Like what are the differences
between serverless vs serverful architecture? For example, we have a Netflix server. If we want to
deploy it on AWS, then what is the difference between deploying it using AWS Lambda vs deploying it
using AWS EC2? Lambda gives us the server facility in which AWS will handle a lot of things for us.
Whereas if we deploy on EC2, then we will have to oversee a lot of things. There is no fixed answer here.
We always have to look at a trade off. Like for example, if we talk about large systems of scalable
systems, then if we use serverless architecture there, then it will become very cost inefficient. So, we
have to think about such things in advance about our system.
Along with this, what is the difference between horizontal and vertical scaling. Like initially, our Netflix
app may have 100 users, 1000 users. So, a single server is enough there. Now as the users increase, we
will want to scale the same server further. Meaning, we increase the RAM in it, increase the storage so
that the same single server can take the load of all our users. So this type of scaling of a single server is
called vertical scaling. Now there is a limit up to which we can scale a single server. There will come a
point after which we will need multiple servers where we are going to use a lot of different servers and
we will also use a load balancer to divide the load on these different servers. So this is called horizontal
scaling. So what are the differences between the two at the fundamental level?
What are threads, what are pages? How does the internet actually work? How does the request
response cycle work? How does DNS work? We should have basic knowledge of all these things.
After that the second step would be to learn about databases. The core of programming and coding is all
about data. It is about transferring data, it is about manipulating data. It is about storing data. Where
storing data plays a various role. That is why databases are the most important part of any system. So
we have Neo 4G in SQL ,No SQL database, Mongo DB. We should know about different types of
databases. In that too which database falls under which category? What are the pros and cons of using
SQL and non SQL databases. Along with this we should also be aware about in memory databases. How
does data replication and migration happen? What is data partitioning? What is sharding? This is also a
very popular interview question. Sharding is basically horizontal partitioning of data which we should
have an idea about in detail because many good companies will ask us about sharding.
Next we are going to learn about consistency and availability. Here we will be learning about data
consistency. What are the different levels? Like what is eventual consistency, quorum consistency and
causal consistency, linearizable consistency.
Along with this we will also learn about isolation and its levels. What are the differences between read
uncommitted and read committed? What is repeatable read. And we will also learn about the CAP
theorem. CAP theorem says that in the event of a network partition we basically have to make a choice
between consistency and availability. Now, which thing we give more priority to between consistency
and availability, which thing we choose, depends on our type of system. Consistency in layman terms
means that we should always get the most recent and the most accurate data. Even if there is a delay in
it. So it basically means that every read should get the most recent write. Similarly, availability means
that our system will definitely send a response. Even if we are temporarily unable to send the most
recent data as a response in a non-error response.
For example, if we talk about Netflix, then we will build a complete system for subscription purchase for
user's payment, there we will give more priority to consistency as compared to availability. Because in
payment systems we have to ensure that we always get all the latest updates. And that is why in
systems like Paytm or PayPal or PhonePe we give more priority to consistency. Another consequence of
this is that generally in payment systems SQL is preferred as a database as compared to no SQL
database. Whereas if we talk about a system like WhatsApp then at the time of WhatsApp notifications
we will give more priority to availability as compared to consistency.
After that we are going to learn about cache. Cache basically stores the data for us which we want to
deliver to the users quickly with a very low latency. So generally this is our most frequently used data or
it is very popular data which will be used by many users. In cache we are going to learn what exactly is a
cache. There are different types of cache in it. There is Redis, there is Mem Cache which exist. How do
they work? There are two important policies in a cache. One is a write policy and the other is a
replacement policy. So what does write back through and around mean in the write policy?
Replacement policies mean that the decision of which new data will come in the cache and which old
data will be replaced depends on the algorithm and the policy that we are using. So there LFU, LRU and
Segmented LRU are some popular options which we should know how they work. And here content
delivery networks also help us a lot.
Basically, CDN ensures fast delivery of static data for us. For example, if there is a popular show on
Netflix like Black Mirror, if a new season or new episode of that is going to be released, then if Netflix
anticipates in advance that there are many people in different countries who will definitely watch this
episode of this season, then Netflix can store the episodes of that new season in its CDN in advance so
that users do not have to wait much longer and can play those episodes for them quickly.
Along with this, we are also going to cover networking in which our basic concepts are what are the
differences between TCP UDP of computer networking? What are the differences between HTTP https?
What are the different versions of http? 1 2 3 What are the basic differences in the implementation of all
three? What are web sockets used for? What is web RTC? And how exactly do we use web RTC in video
streaming? This is a very important use case. And whenever we try to design a system like Google MT or
ZM, its understanding will help us a lot.
Along with this it is also important to learn about load balancers. We talked about horizontal vertical
scaling, so the load balancer has a crucial role there. So what are the load balancing algorithms? What is
stateless and stateful load balancing? There are different algorithms in load balancing. Round robbin is
done, least connections is done. What is consistent? This is an ancient computer science concept. How is
proxy reverse proxy used? Rate limiting which is crucial to prevent a system from DDoS attacks. How is it
implemented.
After that we can also learn about message queues. For asynchronous programming, message queues
are very important for asynchronous processing. And in many systems we get to see message queues.
The basic work of message queues is to handle the non-critical tasks. Non-critical tasks mean such tasks
which even if processed with a little delay will not have any significant impact on the system. For
example, we send our message on WhatsApp. That is a critical task, but whether the double tick is
appearing on the message or not is a slightly non-critical task. Even if there is a little delay in it, it will not
make much difference to us. So this type of task is handled by our message queues. Kafka, Rabbit MQR
is a popular option there. It uses a very popular publisher subscriber model about which we can read.
Along with this, next we will read about monoliths and micro services. One of the two most important
architectures Whenever we talk about building and designing systems, as per the industry norm we are
initially going to build it as a monolith. But gradually as our system becomes scalable, as our teams
become very large, gradually we have to shift from monoliths to micro services. So, why do we need
micro services? What is the concept of single point of failure? How to avoid cascading failures? How
does containerization work? What is the meaning of containers? There are many containers in micro
services. Docker is one of the most popular services for that. And finally how do we migrate from
monoliths to micro services.
Along with that monitoring and logging a system is also variant. For example, we are doing a huge sale
on Netflix subscription and the subscriptions are going to be very cheap. So a lot of users will come to
our system. Now in such a situation, if there is a problem in our system due to heavy load, then the logs
of our system help a lot to identify what exactly is the problem in the system and next time whenever
we have to do a sale, do something, bring out an offer, what are the things we have to pay attention to.
So it is necessary to log events and monitor the metrics of a system. Along with this, anomaly detection
is also an important concept. So here we have AWS Cloud Watch, Grafana, Prometheus. These are the
popular tools that we use.
After that the next step would essentially be to think about security. Like We had already talked about
the fact that only paid users should have access to content in Netflix. For that, there should be strong
authorization, strong authentication inside our system. We generally use tokens. What does O Auth
mean? We have access control list to define the access and different rules for different levels of access
inside the system. We must be talking about encryption. We must be learning about it.
The next step would be to learn about trade offs. Now whenever we talk about system design, there is
no fixed answer, there is no single answer, there is no right or wrong answer. In system design
interviews, basically we have to tell our point of view that we applied this thought process after
understanding the problem. And according to that, we have designed this solution. And then whatever
solution we design, we have to justify it. In the interview, some questions will be asked and we have to
answer them. So designing a system is all about trade offs. It is not necessary that two people will design
the same system in the same way. One person may give priority to something else. The other person
may give priority to something different. So it is very important to understand the trade offs there. So
what is the trade off in push vs pull architecture? Push basically means that we have to push the data
without the client asking for it. In pull architecture we wait for the client to send a request for the data.
And only after that we send our data. Consistency vs availability problem again cap theorem What
differences will we face in trade offs in SQL vs No SQL database? Memory vs latency vs throughput vs
accuracy We will have to choose in these too. So we should have a strong understanding of all these
different trade offs. And as soon as we have learned all these concepts.
Finally the last step is to practice, practice and practice. The more system design questions you practice
the more you become better at system designing. Because generally the bigger the system examples we
take, the more we will learn to design them and the majority of our interview questions will be covered
in them. And in fact by looking at the system designs of different services we will get to know where and
in which cases we will use message queues. In what way we will use cache. Which database should be
preferred where. Where we have to prefer consistency, where we have to prefer availability. So here
these are one of the most popular 10 services whose examples I have given you which are must do and
must practice before we go and sit for a system design interview.
So here YouTube, Twitter, WhatsApp are many popular systems which if we design then we will get an
idea of different types of systems. For example, from Amazon we will get to know what things have to
be taken care of in e-commerce websites. In ZM we will get to know how to view video streaming. In
Instagram we will get to know about a social media application that is dealing with a lot of photos and
videos. How to design it. What things do we have to ensure in Uber according to different types of users.
Two types of users will exist on Uber. One is a rider, one is a driver. Both will have different functional
requirements which we will have to fulfill. So finally we have to practice all these systems. So finally after
learning all of these components this is what our Netflix system is going to look like in which we are
going to have a combination of servers, CDN and load balances. Now there is a common saying in
system design which we can remember for our future self that it is better to satisfy some of the users
than disappoint all of them. And keeping this saying in mind, we have to design our systems.
Now as a software engineer, if we look at the entire HLD topics and syllabus, it seems very
overwhelming at once because generally when we are working on our personal projects and we are
working in a service based company and even in a product based company, as a single software
engineer, we are not dealing with so many things at once and it is completely normal to feel
overwhelmed by all of these concepts. And whenever we talk about working in product based MNCs or
highly scalable startups, generally all these components are being used in their systems in some way or
the other. So as a software engineer, even on a day to day basis we may not be using all these. But still if
we have a good understanding of these, then if we go to work in those companies, then we get a lot of
help in understanding their system and contributing well in those systems. And that is why system
design plays a various role.
Now we have covered high level design.
Next we are going to move on to low level design which is all about machine coding. Under low level
design we can start with the fundamental concepts of Oops. LLD is basically about writing well-
structured code which solves the problems. So inside that we can cover our four pillars and oops.
We can learn about SOLID principles, what is single responsibility principle, what is open close principle?
So in this way there are five SOLID principles which we should know in detail. We can also study about
design patterns.
Now in LLD you will notice that inside LLD you will find a lot of things with which we deal on day to day
basis as a working software engineer. So out of these, you may have already used some patterns inside
your code by companies. We should know in detail about creational structural and behavioral patterns.
Along with that we should be familiar with the concept of concurrency and thread safety. Concurrency is
very important whenever we talk about code. So how does thread safe injection happen? What is the
different locking mechanisms for data? What is the producer consumer model? Are there race
conditions? What is synchronization? These are things that we must have already been studying in
operating systems since college level. We just have to revise them a little.
Then step four would be to learn about UML diagrams. Now within UML diagrams, our class diagram,
component diagram, all these things are covered. UML diagram is basically an optional concept if you
ask me. There are some companies that will expect UML diagrams from you. There are some that do not
want class diagrams to be made. So in such a situation if you have an LLD interview coming up. Then you
can ask your recruiter. You can ask your HR. If this is something which is expected in the interview or
not.
Along with this we are going to learn about API. How will we design our API? Request Response Object
Modeling. Versioning of API or extensibility. We have different clean code principles from which we have
the drive principle, single responsibility principle and along with it how do we avoid God classes in our
code. So these are all important concepts keeping in mind that we have to write our code for our APIs.
After that we are going to practice some of the common problems in LLD. Now in LLD and HLD problems
you will notice a difference that in HLD generally we are designing a large system. And in LLD we have a
comparatively small system which we have to code. Like a T2 or a chess game and maybe you are
designing a notification system and a URL shortener. So in this way there are small systems which we
have to code. No one will tell you in the interview that end to end you have to code the entire Netflix
application because that is not possible even in your time and the interview's time. So this is all which
will be covered in our HLD and LLD interviews.
Now if we talk about the timeline for learning all of these things. If we are someone who is a software
engineer and is actively preparing for software engineering interviews. And there are many of these
concepts which they have been learning and using in their work on a day to day basis. So in such a case
it will take us two to three months to learn all these concepts. But if we are someone for whom majority
of the concepts were new and they had heard for the first time. So in such a case a realistic timeline
would be between four to six months. But the key to learning system design is always practice practice
and more practice. Because the more we practice these concepts, the more we try to implement these
concepts in our POCs, in fact in personal projects, the more we will be able to dive, deep and understand
system design better.
So, I hope that today's session will be helping us positively somewhere in our career. And to the best of
my knowledge, this is going to be one of the most crystal clear. This is going to be one of the most
comprehensive system design guides and system design sessions which will hardly be available
anywhere else on YouTube. That's all for today. See you in the next session. Till then keep learning and
keep exploring.