YT YouTube2Text

YouTube2Text → Transcripts → System Design One Shot Full Course

System Design One Shot Full Course — Transcript

by Telusko · 52,361 words · 7,560 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Welcome back aliens. My name is Vin
0:02Reddy, and in this video we'll talk
0:03about system design. I know you are
0:06waiting for a long time for a system
0:09design course on Telesco, and finally we
0:12are here. Now, in this course we are
0:14going to understand different aspect of
0:16system design. Now, why it is important?
0:18When you go for the interviews, most of
0:20the companies will ask you for system
0:22design knowledge, and the question will
0:24be based on that. Now, of course they
0:26will not be saying this is a system
0:27design round, but they will expect from
0:29you to understand different concepts
0:31here, and how will you solve a complex
0:33problem. And let me give you a statement
0:35which highlights this, and I have it
0:37here. Anyone can write a code that
0:40works. A system design is what makes it
0:44work for million people at once, and
0:48that's the power of system design. See,
0:50when you write a code, of course when
0:51you learn a language, you learn a
0:53framework, you can build application.
0:55That framework can I mean, the entire
0:56project will work. The moment you deploy
0:59it, the moment it is in production, and
1:00when you have users, not just 10 users,
1:03of course it will work for 10 users, and
1:05it should work for 10 users, but the
1:06moment you have 10 million users
1:09accessing that at the same time, will it
1:11work? That's the question. When you talk
1:13about all your favorite applications, it
1:15can be WhatsApp, YouTube, Instagram, or
1:18Amazon for that matter, there are not
1:20few users who are accessing that at one
1:23time. There are millions of users, but
1:25still if you can see, they work. So, how
1:29do we do it? And that's where system
1:31design plays a huge role. Now, to
1:33understand this, we have we will be
1:34going through these concepts. So, in
1:36this particular video, we are going to
1:39start with the basics of system design,
1:41what is system design, what are
1:42different components, data versus
1:45compute intensive, and functional and
1:47non-functional, and all this comes under
1:48foundation. Now, once that is done,
1:51we'll talk about how the communication
1:52happens between different systems. So,
1:54we'll focus on DNS, API, and of course
1:57REST, which you might be knowing if you
1:59have worked with Spring Boot or Fast or
2:03Django and any web framework. Then we'll
2:05move towards the data. Of course, when
2:07you have a lot of users, how will you
2:09store data? Not just their personal
2:11data, but their activities. Uh and in
2:13that we have different options like SQL
2:15databases, no SQL databases, when to use
2:17cache, and when to use SQL and no
2:20non-SQL. Then, let's say your users are
2:23growing day by day. How are you are
2:25going to manage your application? And
2:27that's where scaling and distribution
2:28comes into picture.
2:30In which we'll talk about load
2:31balancers, replication, partitioning,
2:33and the CAP theorem. That this will be
2:35an interesting the CAP theorem. And
2:37then, we'll talk about operations and
2:41reliability. And the most important part
2:43there becomes a fault-tolerant. What if
2:45something goes wrong? Does the
2:46application do have something to do
2:48that? In which we'll talk about message
2:50queues and monitoring as well. And of
2:52course, we'll cover different examples
2:54here to understand different concepts.
2:56And the entire section or this part will
2:59be taken by an amazing trainer, Akshay,
3:01who is very good in explaining stuff.
3:03And I hope you will enjoy the entire
3:05part. And do share your thoughts in the
3:08comment section. Don't keep it blank.
3:11You what you like, what you don't like.
3:12If you have any questions, do point it
3:14there. And we'll try to answer them. And
3:16if you enjoy this type of videos from
3:18us, let me know in the comments as well.
3:20That is our motivation. And I hope
3:22you're motivated. Let's get started.
3:24Akshay is all set.
3:26>> [music]
3:28>> Hello everyone. Welcome back to
3:29Teleschool. My name is Akshay Agarwal.
3:31And today, we are going to start the
3:33system design course. In this course, we
3:35are covering each and every topic which
3:37includes in system design. So, let's
3:39start with understanding why do we need
3:41system design at all? In systems, we
3:44have a lot of systems around us. If we
3:46talk about human body only, we have
3:49digestive system. And also, we have a
3:51system. Along with this we have a lot of
3:53systems, but these kind of systems are
3:55pre-built. It means we have not created
3:58them. We just discovered them with time
4:01and we got to know about various
4:02components which are required for us to
4:05breathe or to digest our food. So, in
4:08these systems as they are not built by
4:10us, we can't actually change anything.
4:12Maybe through surgery we can change some
4:14of the other component, but not much.
4:17But the kind of system we talk about in
4:19IT industry are the systems which are
4:21built by human or engineers like us
4:24only.
4:25So, in that there is a possibility that
4:27we can pick our systems based on our
4:29requirement and also based on our
4:31requirement we can pick the components
4:34which are required in our system and we
4:36can basically improve our system based
4:38on the request we are getting, based on
4:41the load our system is managing, based
4:43on the kind of traffic which we are
4:45getting in our system. So, in system
4:47design if we go through the words we
4:48have two words here, right? One is
4:50system and one is design. What is a
4:52system? If we go through the definition,
4:55system basically means there are a lot
4:57of components. There can be more than
4:59one components in that system. So, let
5:02me write components. And those
5:04components are working eventually to
5:06solve a particular use case or maybe
5:08multiple use cases, but the common
5:10purpose of the application remains same.
5:12So, that means if we write system is
5:15equal to components plus common goal,
5:18this sums up our definition of system.
5:20Now, when we talk about design, there
5:22are various components which we are
5:24going to learn and there are various
5:26common goals based on the requirement
5:27analysis of different applications which
5:29we are going to cover in this particular
5:31series. But in order to start, let's not
5:34dig too much into the technical details
5:35in this video. Let's start from a very
5:37basic. Let's say we have a requirement
5:40of creating our own application or our
5:43own bank. Let's say we have a bank named
5:46Alien Bank because we are in Telesco,
5:48why not? And in this bank, we are not
5:51dealing about each and every operation.
5:53Currently, we have a single operation,
5:55which is we have a cash counter, and we
5:58have a person sitting on a cash counter.
6:00Let's name it as cashier. Okay, so here
6:03we are ready with our cashier, who is on
6:05our cash counter, and the requirement or
6:07the flow is pretty simple. For the flow,
6:09let's understand the concept of our
6:11bank. So, we have multiple, let's say,
6:14customers are here, and each customer
6:17will come to our counter, either
6:19withdraw or deposit some amount, get the
6:21receipt from the cashier, and then move
6:23forward. So, let's write it down as
6:25customer flow cycle. So, in our customer
6:28flow cycle, there are four steps,
6:29basically. Customer first will visit the
6:31counter, will come to the counter, then
6:34the customer will either withdraw or
6:36deposit some amount, take the receipt
6:38from the cashier, and then the
6:39transaction is done. The purpose of our
6:41application is done. So, these are the
6:43core functionality of our system. It is
6:45very basic, very easy. You might have
6:47seen this already in some of the banks.
6:49So, we are building the same
6:50architecture right now. The architecture
6:52basically looks like this. Now, in order
6:55to understand system design, what it
6:57really is, and how we are going to
6:59improve the working of our Alien Bank,
7:01let's face some issues. We are going to
7:03face five issues, and based on the
7:05issues and solutions, we are going to
7:07understand how system design looks like.
7:10So, here comes our first issue, which is
7:12the process is really slow. By slow,
7:14what we meant is, let's say, our cashier
7:17takes 10 minutes per customer. So, that
7:20means we are serving only six customers
7:22in 1-hour span. So, this is a huge
7:25issue, because if the number of
7:26customers will increase to a limit, and
7:29also we have rush hour, in those cases,
7:31our system will break, and we will be
7:33not able to serve the customers rightly.
7:35So, in order to improve this, let's
7:37first focus on our cashier. So, let's
7:39understand our system from the cashier's
7:42point of view. So, basically, our
7:44cashier is taking time to understand the
7:47requirement. By requirement, I mean
7:49whether the customer needs to deposit
7:51the amount or customer needs to withdraw
7:52the amount. They have to make this
7:54interaction, which is time-consuming,
7:55right? Now, once the requirement is
7:57locked, whether the customer is going to
7:58deposit the amount or withdraw the
8:00amount, the cashier manually have to
8:02count the cash. And then our cashier
8:05will prepare a receipt, which will be
8:06again given to our customer. So, these
8:09are the time-consuming tasks for our
8:11cashier. How can we improve the cashier
8:13time? So, in order to improve the
8:15working of our cashier, we have three
8:17major issues. First is they are not able
8:20to understand the requirement. Next is
8:23they are counting the cash manually,
8:25which is taking time. And again, they
8:27have to prepare the receipt. So, these
8:29are the issues which our cashier is
8:31feeling, and we are trying to solve
8:33these issues. Maybe we can train our
8:36cashier in order to count the cash very
8:39rapidly. Okay. Also, our cashier is also
8:42responsible for maintaining the receipt.
8:44So, we will improve the typing speed of
8:46our cashier in order to make the receipt
8:48very fast. So, the second thing is train
8:51to type fast. So, with this, what we are
8:54doing, we are not adding any resources
8:56to our cashier. Simply, we are making
8:59our cashier super fast, right? We are
9:02improving the skills of our cashier,
9:03which is required for them to maintain
9:05this job. And let's say through this
9:07training, the cashier is really improved
9:09now.
9:10He is or he or she is now taking, let's
9:13say, 5 minutes in order to fulfill one
9:17customer's need. So, this is a huge
9:19improvement. By this, we are able to
9:21improve the process by 50%. So, let's
9:24say our second issue is that the
9:26customers which our cashier used to
9:28attend are increasing very fast, because
9:31this is our alien bank, and it is
9:32working very fastly, right? Growing very
9:34fastly. So, now the issue two is our
9:37customers count is increasing. This is
9:40our issue two. In this case, what we
9:42know so far? We know that our cashier we
9:45can't improve our cashier performance
9:46because it is now at its peak. So we
9:49have to basically handle some or the
9:51other components to our cashier in order
9:53to make the work very fluently. So maybe
9:56the desk on which our cashier is
9:58sitting, we will increase the size of
10:00desk. So next thing which we can do is
10:02we will provide the cash counting
10:04machine to our cashier so that the
10:05manual cash counting time will get
10:07reduced, right?
10:09So we'll provide cash counting machine,
10:12right? So with this also the time will
10:14get reduced and our cashier will be able
10:17to attend more customers. One more thing
10:19we can do that is instead of coming to
10:22counter and getting the requirement at
10:24the real time, we can give a form in
10:27advance to all customers so that they
10:30can fill it and our interaction time
10:32will get reduced, right? So our cashier
10:35will now don't have to communicate each
10:37and every request to our customers.
10:39Uh they can simply see the form and
10:41based on the form they will fill out the
10:44thing. And now our cashier have cash
10:47counting device also, so the process
10:49will be fast. Let's say through these
10:52processes, through enhancing our desk or
10:54cash counter, the timing got reduced
10:57from 5 minutes per customer to 3 minutes
11:01per customer. This is also a huge
11:03impactful thing. So now our cash counter
11:05is capable of attending more customers
11:08in lesser time. So that means even if
11:10the customer count is increasing, we
11:12will be able to process more customers
11:14and enroll more customers into our Alien
11:17bank. So this issue is also kind of
11:19solved. Now let's move to the third
11:21issue. The issue three is our customers
11:24are still waiting to get their
11:25application resolved, right? Currently,
11:28what do we have? We have our cashier who
11:30is upgraded to its maximum level. So, we
11:33can't upgrade the cashier more. Also,
11:36the desk on which it is sitting, the
11:38cash counter, is also upgraded to its
11:40maximum limit. So, we can't upgrade our
11:42cash counter more. So, these two things
11:45are pretty solid right now. We can't
11:47improve it now. Now, the thing is, so if
11:50we have 10 customers in place, that
11:52means our 10th customer will have to
11:54wait for 27 minutes in order to process
11:58the three-minute work. So, that is a
12:00huge drawback of our system right now.
12:02And why that drawback is coming? Because
12:05we have only single cash counter in our
12:07system. So, in order to make the process
12:09more feasible, now we have reached that
12:12point that we have to add more cash
12:14counters into our system.
12:16So, let's add them. So, now we have our
12:18cash counter one and cash counter two.
12:20Now, at this point, we have added one
12:22more counter, and things are pretty
12:24solid right now. So, our customers will
12:28eventually have two counters to go to,
12:30and both of those counters will be able
12:32to solve our issues. It feels good,
12:34right? Now, we have two counters to
12:35process. So, our customers will not have
12:37to wait for longer time. They can either
12:40go to counter one, or they can go to
12:41counter two. But, let's say if first
12:44customer is going to counter one, and
12:47the counter one is able to process the
12:49information, and they are maintaining
12:51their own data. And similarly, our
12:53second counter is also maintaining its
12:55own data. And they are not synced. So,
12:59this creates two issue, right? First
13:01issue is, if in our system, the counter
13:04two doesn't know anything about the
13:06customer, that will create an issue
13:07because they have a valid account in our
13:10bank, and they should be able to proceed
13:12their information through it. Now, the
13:14second issue is this only. That from the
13:18first account, they can also withdraw
13:20the amount, and they will not update the
13:23second counter. So, that means they can
13:25again withdraw the amount from cash
13:27counter two also. This will create an
13:29issue of data discrepancy. That means
13:31our data is not synced. So, the fourth
13:34issue here is we need to have a
13:35centralized database or central data
13:38from which the cash counter one and cash
13:40counter two will go and validate the
13:43data and go and retrieve the data. If
13:45the account is there for any customer
13:48and the amount is also there, so the
13:50customer one will also insert the cash
13:53into the same account. And if the
13:55counter two is getting withdrawal
13:56request, they will also get the amount
13:59out of the same account. So, in order to
14:01fix this, we need to have a centralized
14:03data. That means our counter will look
14:05like this. This is our counter, let's
14:07say two. This is our counter one. And
14:10they will eventually connect to a
14:12centralized database. And as it was
14:14before, our customers are standing in a
14:16queue waiting for their turn to come in
14:19order to get the request. Now, after
14:22solving all these case also, we have a
14:24new issue in hand. Which is, let's say
14:27the gate of our bank is here. This is
14:29our alien bank. So, since the gate is
14:32here, most of our customers are going to
14:35the cash counter one only, where cash
14:37counter two is sitting idle. Or maybe
14:40processing lesser request, far lesser
14:42request than the cash counter one. This
14:44will again end up adding the wait time
14:46to our customers. And again, we will be
14:49end up handling lesser customers than
14:51our potential. So, let's write that
14:53down. This is our issue five, which is
14:55underutilized counter. Now, in order to
14:57solve this issue, we need to have a
14:59middleman. Which will stand apart from
15:02our counters. Let's say this is our
15:04counter two. Again, this is our counter
15:06one. And here are our customers. And now
15:10our customers will not go to the counter
15:12directly. They will first go to this
15:14middleman. Then the middleman will check
15:17how much load each counter is handling.
15:20Suppose there are 10 customers at
15:22counter one and only five customers at
15:24counter two, then our middleman can
15:27decide that next customer should go to
15:30the counter two.
15:32And the count will increase to six,
15:33right? And the next customer will again
15:36go to counter two, and the next customer
15:39is again going to counter two only.
15:41When the limit reach, let's say we have
15:4311 customers here and 11 customers here.
15:47And if then any new customer arrive,
15:50they will again ask man where to go.
15:52Let's say on some fine day our counter
15:55one is not working. That means our
15:57middleman will know about this and will
15:59eventually send all the customers to
16:02counter two until the counter one is
16:04getting fixed. So, let's end this
16:06example here at this particular point
16:09and see what have we learned. Through
16:11this story, through this single story
16:13and five issues, I have tried to capture
16:15multiple concepts of system design. So,
16:17the first concept which we discussed is
16:20designing a system, that is for sure.
16:22Ultimately, what design we do have here?
16:25We have one cashier and the other
16:27cashier. Each cashier is having their
16:30own counter. So, this is our counter
16:32two, maybe this is our counter one. We
16:34have a number of customers waiting for
16:37us. Also, we have a middleman now. With
16:40that, we also have a common database,
16:43okay? So, this database is nothing but
16:46centralized database. The customers
16:48which are coming to our bank is nothing
16:51but requests. And if they are standing
16:54in a queue, we can say they are creating
16:56a traffic, okay? So, these are the
16:58traffic which we are going to handle.
17:00Now, all the requests or all the traffic
17:03is coming through a load balancer, the
17:05middleman. So, this is nothing but our
17:08load balancer. So, from the load
17:09balancers, all the requests are coming
17:11to either of the cash counter. So, we
17:14can say that our cash counter is nothing
17:16but servers. And the person sitting
17:19there doing the work is nothing but our
17:21application code. Now, let's see the
17:23system again through the system design
17:25point of view. So, the first issue which
17:27we have was our process is slow. So, in
17:30order to solve that, we improved our
17:33code quality, right? So, first thing
17:35which we do in our systems also, we
17:37improve our code quality. So, this is
17:39where our LLD will come and this is
17:42where our DSA will come. Suppose a
17:44particular loop is taking certain time,
17:47we can reduce that loop or we can change
17:49that loop to some for each function or
17:51some other way in order to process that
17:53information fast. So, while solving the
17:56issue two, we increase the size of our
17:58table, we added some functionality, we
18:00added this cash counter. That means we
18:03upgraded our server. So, in order to
18:05upgrade our server, this term is called
18:07vertical scaling. In vertical scaling,
18:10we don't add multiple servers, we
18:12basically update our current server
18:14only. And again, the current server
18:17updation have a particular limit. After
18:19that limit, you can't upgrade your
18:21system. So, then comes the issue third,
18:24which is our customers need to wait for
18:27the single server to respond. So, in
18:29this case, we added more servers. So, in
18:31this scaling, we added more server that
18:34is called horizontal scaling. So, after
18:36having multiple servers, we need to
18:38maintain the data at the common point.
18:40So, that's why we added databases. And
18:43in order to add a common database, we
18:45basically can move to distributed
18:47database architecture or can move to a
18:49centralized approach of handling that
18:51database. So, this is nothing but
18:54centralized database. So, after having
18:56centralized database, again the issue
18:58comes where we don't know how to handle
19:01multiple requests. That means our
19:03requests are again going to one counter
19:05only or one server only. Now that we
19:08know they are going to one server only
19:10and the other server is underutilized.
19:13So, what we did, we added a middleman.
19:15Our middleman is no one but our load
19:18balancer. Our load balancer basically do
19:20two things. They will check whether our
19:22servers are healthy or not and based on
19:25that, they will distribute the request
19:27equally into multiple servers. So, these
19:29are all the concepts which we discovered
19:32through this particular example. So, if
19:34we think about the applications we are
19:35using in our day-to-day life, we are
19:37using WhatsApp, we are using maybe
19:40Snapchat, we are using Instagram, we are
19:43using YouTube, we are using LinkedIn, we
19:46are using Netflix, Amazon, maybe
19:48Flipkart. All of the applications, if we
19:51think about it, are showing us the data
19:53either in the form of images or in
19:56videos, in audios or in text. So, we can
19:59say through a large lens, the data
20:02consist of these four kind of
20:04information. And all of the applications
20:06which we are using in our day-to-day
20:07life consist of these data's only. So,
20:10we can say that in the core of every
20:13system, we have data and we are then
20:15finding ways to make it available to the
20:18users in the way they are expecting it.
20:20So, in the center, as we discussed, we
20:22have data. Data can be of various form.
20:25It can be image, video, audio or text.
20:30Now, if we think about data, it is not
20:31like we are seeing the data once only.
20:34We have to see the data and also while
20:36storing also, we need to store the large
20:39amount of data. Now, in order to store
20:41the data, we do have databases. So,
20:43databases are basically our first
20:45component of system design. What is
20:48functionality of databases? Pretty
20:50simple. We need to store our data and
20:53whenever we want to retrieve some data,
20:54we need to get the data from our
20:56databases only. They are represented by
20:58this cylindrical figure. Databases can
21:01be of multiple ways. It can be
21:03categorized into no sequel or sequel.
21:06Now, there are various kind of databases
21:08in both of these categories. In sequel
21:11also, we have various databases from
21:13which we can select which database we
21:14are going to use. And similarly, in no
21:17sequel also, we have various kinds of
21:19database from which we can pick which
21:21database we need for our application
21:23right now. But, the core remains seems
21:26that we are saving our data in some or
21:29the other database. We will discuss
21:30about sequel and no sequel databases in
21:32the coming videos. That's why I'm not
21:34going to deep into this at this moment.
21:36Let's think about the scenario where you
21:39and every user on the planet knows the
21:41queries of database, knows how the
21:44tables are structured if we are talking
21:46about sequel, or how the documents or
21:48nodes are connected if we are talking
21:50about no sequel. If we talk about both
21:52of these scenarios, if user, the end
21:55user, already know the database query
21:58languages and know how to deal with
22:00different kind of data, in that case, we
22:02might not need any application if you
22:04think about it. We will simply go to our
22:06database, or the database will be
22:08accessible throughout every application.
22:11Suppose we are seeing the LinkedIn, but
22:13on LinkedIn we will see an interface on
22:15which we will write our query, and the
22:17data will be fetched to us. That will be
22:20an hectic task. But, if users know about
22:23that, and if users start exploring that,
22:26that will be easier, right? In that
22:27case, we don't need any application
22:29layer in between us, and in that case,
22:31we don't need any client-side
22:33application also between us. We simply
22:35will see a database, query it, and get
22:38the results, right? In that case, what
22:40will happen? Each query have to be
22:42managed through the users only. And
22:44these queries, when I talk about large
22:46systems, let's say we are talking about
22:48LinkedIn, there can be multiple tables
22:51through which our data is curating and
22:53coming to us. Every user can't do it,
22:56right? That's why we have different
22:58layer in front of our database, which is
23:00our application code. So, in application
23:02code, what we do is we hide the
23:04complexity of dealing with databases,
23:07different tables, different documents,
23:09and we give the endpoints to our
23:12application or to the world so that they
23:15can access the kind of information they
23:17are looking for. For that, we create
23:19APIs or we can say we create endpoints.
23:23There can be multiple endpoints based on
23:25different features, based on different
23:27operations. So, through endpoints, we
23:30communicate to our application, which
23:32will again communicate to our databases
23:35to get the data we are trying to get.
23:37There can be various operations, like we
23:39can insert some data, we can update some
23:41data, we can retrieve some data, we can
23:44delete some data based on our request.
23:47So, the thing becomes little easier to
23:49us. Now, we don't have to deal with all
23:52the database tables, but now we have
23:54assigned endpoints through which we can
23:56do the work which we want to do. And
23:58endpoints are pretty simple.
24:00So, in order to get some data, we have a
24:02get endpoint. Let's say https, and here
24:07comes our Teleschool. So, this URL or
24:10this endpoint can be used to fetch all
24:13the students which are there in our
24:15Teleschool environment. But then, what
24:17we are doing? By introducing application
24:19code, we are moving our logic and data
24:22separately. That means we need some kind
24:25of connections between these two. In
24:27which we can connect through IP
24:29addresses, we can connect through some
24:31HTTP protocols, or we can connect
24:33through some TCP protocol. There are
24:35many ways of connecting the database
24:38from the application code and getting
24:39the data which we want. So, in order to
24:41show the APIs or in order to interact
24:43with the APIs, we have to know what is
24:46JSON and how we are going to send the
24:49data to our APIs and how we are going to
24:51fetch the data from our API.
24:54In this level also, if we know how to
24:56handle JSON, if we know how to handle
24:59various operations through which
25:01endpoint, it will make our life little
25:03easier than accessing the databases,
25:05right? So, in that case, we don't need a
25:08front end if we know how to hit the
25:10endpoints through which we'll get the
25:12data. But, for our normal users, for
25:15other users of any applications, this is
25:17also a tedious task. So, in order to
25:20make this easier, we have a different
25:22layer between our system that is our
25:25client application. Client applications
25:27are nothing but the applications through
25:29which we are interacting to the
25:30database, through which we are getting
25:33those databases. So, our client
25:34applications, be it a mobile
25:37application, be it any web application,
25:39be it any ATM machine for that matter,
25:42they are connected with the application
25:44code, and further, the data is being
25:47consumed by us. So, again, in order to
25:49connect the application layer and the
25:51client code, we again need some kind of
25:54communication between them. We either
25:56can go to the same HTTP or TCP or maybe
26:00IP. Now, we have our application ready
26:02in our hand and we can use it. So, if I
26:04draw it like we used to draw it, this is
26:07represented by our client, either a
26:10desktop or a mobile device. Now, they
26:14are sending queries to our application
26:16code, and our application code is
26:18further getting the data from database.
26:21Now, for our client to communicate with
26:24our application code, we need to put our
26:26application code on any server. And now,
26:29if we think about it, our application
26:31code is already exposing the APIs to our
26:34client. That means, it can also expose
26:38the APIs, or any other application can
26:40also use our application codes through
26:44our APIs and do the work which is
26:46needed. So, it can be connected to any
26:49other server also, which will contain
26:51their application code. And this will
26:53communicate with our data through our
26:56application code. For every query which
26:58we are making, we are going to our
27:00database, and from that we are getting
27:02the data which we are trying to get. So,
27:04if we think about it, most of the
27:06communications will start from the
27:08client side, and they will come to our
27:10application code through which we will
27:12get the data from the database. This is
27:14pretty much the easy application or the
27:17applications which we create on our
27:18college projects look like. Either a
27:20to-do application or a simple chatting
27:22application will look like this. Now, in
27:24the current scenario, what we are doing
27:26with this kind of architecture is every
27:28client is going to ask application code
27:32for some or the other information, and
27:34to fetch the data, our application code
27:36needs to get the data from the database
27:38only. We don't have any other option. In
27:41order to make the files accessible to
27:43our server faster, because the
27:46database's calls are heavy, which will
27:48take a lot of time, let's say, if a
27:50database query is finding the columns
27:53from 12 tables, it is going to take
27:55time, right? Now, in order to make the
27:57frequently used data accessible faster,
28:01we have a different layer, which is
28:03called cache. When we are going to put
28:06any data into our cache, and when we are
28:09supposed to remove the data. There are
28:11different strategies we are going to
28:12cover that also in the upcoming videos,
28:15but for now, let's see, this is our
28:17cache, and all the frequently used data
28:20will be stored here. So, that we don't
28:22have to call to our database, and they
28:24can be easily accessible through our
28:26cache only, which will make our process
28:28slightly faster. So, this is our fourth
28:30component of our system, which is cache.
28:34Now, let's move forward. Let's say our
28:35application is big, is having multiple
28:38servers. In that case, we may have some
28:41client or this client, either the mobile
28:43application or the web view, and we are
28:46getting the data from multiple servers.
28:48Let's say this is server one or this is
28:51server two. Now, when we have two
28:53servers or multiple servers, our client
28:55have to decide where to go. From where
28:58do we fetch the information? Now, in
29:00order to take this control, we have a
29:02load balancer in the middle, which will
29:04take care of each and every request and
29:06which will take care of each and every
29:08connections of the server. So, our load
29:10balancers are responsible for handling
29:13two tasks. First, they will check
29:15whether the server is healthy or not.
29:17And second one, they will divide the
29:19request for each servers equally. This
29:22is what our fifth component looks like.
29:24Now, let's come to our next component,
29:26which is messaging queue. So, in order
29:29to understand message queue, let's first
29:31understand that in order to process one
29:33operation, there can be multiple task
29:35into that operation, right? Let's say we
29:38are ordering something. So, when we are
29:40ordering, we are going to do multiple
29:42tasks, right? We are first creating an
29:45inventory update. Next is we are going
29:47to process the order also. We are going
29:49to talk to the vendor who is going to
29:51take the delivery. So, we are going to
29:53handle delivery. And then, we are also
29:55trying to send you the information, the
29:57notifications that your order is placed
29:59successfully. Don't worry about it. So,
30:01that means we are going to handle the
30:02mail service or the SMS service also.
30:06Now, in order to handle multiple
30:08services like this, we can't wait for
30:10every application to respond back. There
30:12are two kind of applications basically.
30:15First is, let's say this is an
30:16application and this is another
30:17application. Let's say this is SMS
30:19application and this is our order
30:21application or microservice for that
30:24matter. Now, whenever an order is
30:26placed, it is going to speak to the SMS
30:28service or SMS application to send the
30:31message to the user that your order is
30:33placed successfully. Now, there can be
30:35two ways of handling this. First way is,
30:37whenever the SMS is sent, they will
30:40notify the order service or the order
30:43application back that we have sent your
30:44message done. Or there can be different
30:47way of handling it that from our order
30:49service, we simply say that okay, this
30:52is our order information. Please send
30:54the message to this number and we are
30:56done. We will not wait for the response.
30:59We will move forward with our
31:00application and with different orders.
31:03So, the kind of requests in which we are
31:05waiting for any confirmation or any
31:07feedback from the other service are
31:09called synchronous calls. And the kind
31:11of service in which we will simply put
31:13down the service and we are not waiting
31:15for any confirmation, we will move
31:16forward to do our task. Those are called
31:18asynchronous services. Don't worry about
31:21this if you don't understand it now. We
31:22are going to dissect each and every
31:24component in details in the further
31:26coming videos. So, for asynchronous kind
31:29of services, what we can do, we can
31:30simply push our notification or push our
31:32request to another service and move
31:35forward. So, in those kinds of services,
31:37we have a message queue or message
31:40broker in middle. What it will do, we
31:42are having our order service here. It
31:45will put multiple request or can put a
31:48request time to time into this message
31:51queue. And then all the requests which
31:54our order is processing through message
31:55queue, they will not take care of it
31:57anymore. Our message queues will take
32:00care of it. They will connect with our
32:02SMS service or SMS applications and send
32:06the request one by one. And they will
32:08take care of these all operations. So,
32:10our message queue is like a broker who
32:13will take the request from one
32:14application, store inside it. They will
32:17take care of these applications. They
32:19will take care of the retries or if any
32:22request is failing, they will take care
32:23of it. Maybe they will communicate to
32:26our order application in the end or in
32:28the end of each day, we will send some
32:31notification, some batch processes to
32:34our order application in order to show
32:37that which requests are fulfilled and
32:39which are not fulfilled. So, in short,
32:41our messages queues are doing two work
32:44here. They are storing each and every
32:46request which are coming from various
32:48other services or various other
32:50applications for that matter. They are
32:52storing it and they are taking care of
32:54those requests. They are sending those
32:57requests finally to SMS application or
32:59service and they are taking charge that
33:01okay, my first service or my first
33:04request is being processed. Nice. Now, I
33:07will send the next request. Now, I will
33:09send the next request and further on. If
33:11it is failed, there are various
33:12mechanisms how messages queues work and
33:15how they bisect and dissect each and
33:17every request and make sure that they
33:20will provide the latest status of each
33:22request. And in those kinds of
33:24environment where we have multiple
33:25microservices, in those cases message
33:28queues plays a vital role in between
33:30them. And with that, let's move to our
33:32final component which is monitoring and
33:35logs. In monitoring and logs, what do we
33:37do? As we know now, we have different
33:39components in our architecture, we have
33:42a client system here.
33:43We may have a mobile application again
33:46which is connecting through an API to
33:49our load balancer
33:50which is again further connected to
33:52either server one or server two.
33:55Our servers are the area in which we
33:58have our application code and then they
34:01may be connected to single database or
34:03multiple databases and those databases
34:06can also communicate with each other in
34:08order to maintain the data. And also,
34:10let's say our application is also using
34:12some third-party application for which
34:14we are using message queues. Our message
34:17queues are denoted by this. Now, this is
34:19our architecture. We have so many
34:21components.
34:22So, it is very important for us to
34:24monitor those components. To monitor
34:27whether our load balancer is working
34:29finely or not. To manage whether our
34:32application code does have any error or
34:34not. And if there is an error, we need
34:37to know how to solve it. We need to know
34:39the complete stack trace of that
34:41particular error. We need to know how to
34:43reproduce those errors on our local
34:45system in order to fix them. And also,
34:48while working with the applications, we
34:49know that for every each and now, we
34:52have multiple features which are being
34:54attached to our applications. So, we
34:56also need to monitor while adding one
34:58more feature to our application, whether
35:00any other feature is impacted or not, or
35:03it is failing or not. So, in order to do
35:06that, we have a lot of monitoring tools
35:08and also logs to check our system. There
35:11is a complete testing department in our
35:13team also, who takes care of these
35:15things. This is one of the vital role in
35:18our application. So, these are most of
35:20the common components which are used in
35:21system design. Whenever we think about
35:24any application or designing any
35:25application, we suddenly jump to the
35:27tools which are used in that
35:29application. We start creating diagrams
35:31that this is our client, this is our
35:33database, this is how our data is going
35:35to flow, this is how we add cache maybe.
35:38So, these all things we start doing
35:40without noticing a single thing, that
35:42is, how is our application going to
35:45work?
35:46What is this application? What are the
35:48limitations of this application? In
35:50system design, there is a smart way of
35:52doing that. First question you need to
35:54ask yourself before diving into the
35:57solutions is, what is this application?
36:00What is the type of this application? Is
36:03it a data intensive application or a
36:05compute intensive application? With this
36:08common differentiation, you will be able
36:10to save a lot of cost to your system
36:12design, as well as you will be able to
36:15handle the task properly into your
36:17system. Let's say, we have two
36:20applications. In both of these
36:22application, there are the same number
36:25of users. With that, the network on
36:27which both of the applications are
36:29working are also pretty much same. Now,
36:32let's put a scenario that our system or
36:34the application which we are working on
36:36is facing latency. Now, what is latency?
36:40Latency means our system is taking time
36:42to respond. There are various ways of
36:44handling this issue, of fixing the
36:47latency issue. We can add multiple
36:49databases, we can add different caching
36:51layers, we can update the caching
36:52mechanism, or we can update
36:55or the CPU powers. Now, on which vector
36:58we are going to do this changes defines
37:00how well we are going to solve this
37:02issue. So, now there are two type of
37:04applications as I discussed. One is data
37:06intensive application and one is compute
37:09intensive application. Let's understand
37:11them one by one. The basic difference on
37:14which data intensive application is
37:16different from a compute intensive
37:17application is that in data intensive
37:20application our core focus is on data.
37:23Now, for this data we need to have
37:25multiple operations, right? We need to
37:26store the data, plus we need to gather
37:29the data, we need to move the data time
37:31to time. That means we need to keep
37:33updating the data because new data is
37:35entering. And also, while new data is
37:38entering we can also, right, we need to
37:39add a lot of data.
37:41We can take example of any application
37:43which can be Instagram because on
37:45Instagram we see a lot of content and we
37:48post a lot of content. So, that is a
37:50data intensive application where the
37:52primary focus is on gathering the data,
37:55is on showing the data, is on the data
37:57you are posting. But, the focus is not
37:59on how the data will be calculated. The
38:01calculation part is pretty solid. We
38:03just need to move the data from our
38:05databases to the client applications and
38:07we are sorted. So, in these kind of
38:09systems the data mainly resides in the
38:12database. So, first issue can be the
38:16database response is low. Another is,
38:18since we are using network calls here
38:20and there, that means our network calls
38:23are also bulky or we need to optimize
38:25them. The third can be our server itself
38:27that our server configuration is pretty
38:29low, that's why we are not able to get
38:31the data faster. So, all in all, in
38:34data-intensive applications, we are not
38:35blaming the client to upgrade their CPU,
38:38we are blaming our circle, our database
38:41calls, our network calls, our server
38:43configuration in order to get the data
38:45fast. Most of the applications in which
38:48you work on are data-intensive
38:50application. That's why we use terms
38:52like cache enhancement, shredding, and
38:55through all of those things we will be
38:56able to solve this issue. Now, let me
38:58also write some common examples of this.
39:00So, the common examples here are
39:02Instagram feed where we see a lot of
39:04data as we discussed earlier. In
39:06WhatsApp messages also, there is a high
39:08amount of data because we are not only
39:10taking care of one chat, we are taking
39:12care of entire chat. The count of chats
39:15or the count of messages WhatsApp deal
39:17with is around 2 to 10 million messages
39:20per day. So, this is also a heavy
39:23data-intensive application. Now, there
39:26are bank transactions, analytic
39:28dashboard, and log process system as
39:30well. In all these application, the
39:32primary goal is to serve the data from
39:35database to our client system faster.
39:37There is not much calculation required
39:40for them to show on the client machine.
39:42Now, based on the data-intensive
39:43application, what are the worries of a
39:46data-intensive application? The first
39:48worry is how fast can we read the data?
39:51The second point is how safely are we
39:54going to store the data? The third
39:56point, as we all know, a lot of users
39:58are using our application, so how many
40:00users can use the same data
40:02simultaneously? The next and one of the
40:05most important worry of these kind of
40:07application is what if any server dies?
40:10What if any server breaks? What if any
40:13network call breaks? What if any
40:15database machine breaks down? So, in
40:18those cases, how we are going to handle
40:20the data? So, these are the most common
40:22worries of the data intensive
40:24applications. And now, in order to solve
40:26them, we don't go to our client system.
40:29We talk about the components on which
40:32these processes lies. And those are our
40:35databases, caching, replication, maybe
40:38data sharding, or it can be solved
40:41through data consistency. So, these are
40:43all the components or the terms we use
40:46in order to improve our data intensive
40:48application. Don't worry about these
40:50terms if you don't know them yet. We are
40:52going to cover each and every component
40:54in details in the coming videos. So, I
40:56hope data intensive applications are
40:58pretty clear up to now. But, for the
41:00sake of example, we are also going to
41:02take one more example. Now, think about
41:04Instagram feed. We are not solving
41:06Instagram feed issue through any
41:09mathematical equations. We just have to
41:11gather a lot of data and show you that
41:13data. So, what we don't do here, we
41:16don't do any complex maths. What we do
41:18then? We normally fetch the posts. After
41:21fetching the post, we sort them through
41:24time or relevance. We show a lot of
41:26images or videos. And according to those
41:29content, we normally do some operations,
41:33maybe like or commenting or sharing. So,
41:36I'm writing that. So, this is all the
41:38operations loosely we have on the
41:41Instagram feed. Now, what is the common
41:43challenge which Instagram is facing
41:45daily? That is we we have a lot of
41:48content. We have millions of users and
41:51million of content which we have to
41:53handle. So, let me write that down. In
41:55other words, we can also say that
41:57million of users are reading and writing
42:00at the same time. So, with this
42:01challenge, Instagram still needs to
42:03scale, right? How does Instagram scale?
42:06If we think about this, Instagram adds
42:09multiple databases in order to store the
42:11data. And also, Instagram uses
42:13aggressive caching in order to store or
42:16get the data fast. Now, we also know
42:18that Instagram heavily depends on the
42:20images and the video content form. So,
42:23in order to handle them, we can't simply
42:25store those kind of data into our
42:27databases directly. For that, in order
42:29to fetch them faster, we need to have
42:32certain CDN in place. And in databases,
42:35we will only store the location of that
42:36particular file which we are going to
42:38fetch through the CDN. Now, think about
42:40this. In order to fix the latency issue
42:43on Instagram or in order to help
42:45Instagram scale, we hardly touch the CPU
42:48or we hardly touch any GPU. We only
42:51touch the data or the components which
42:54are associated with them. Because the
42:56issue here is not the CPU, but the data
42:59movements between the components. Now,
43:01this is all about data-intensive
43:03applications. Let's now focus on the
43:05compute-intensive applications. Now, the
43:07compute-intensive application is exactly
43:10opposite of a data-intensive
43:12application. Here, the amount of data
43:14which we are retrieving from databases
43:16are pretty much low, but the
43:18calculations we need to perform are
43:20really heavy. So, instead of putting our
43:22focus on database caching, replication,
43:26sharding maybe, we move our focus from
43:28there to CPU and GPUs. So, let me write
43:31down the challenge now. So, we can
43:33safely say that here our systems are
43:36compute-bound or we can say CPU or
43:39GPU-bound. Let me take some examples of
43:41this. The most common example can be
43:44image processing, video rendering. The
43:46machine learning model training can also
43:48be a good example of this. Also, we can
43:51talk about simulation and cryptography.
43:54Now, in all these examples, the data
43:56which we are getting from the database
43:58are in a smaller level only, but the
44:01kind of processing we need to do in
44:02order to show these data to user is
44:05heavy. That's why they come under the
44:07category of compute intensive
44:09applications. Now, let's discuss about
44:11the worries of a computer intensive
44:13application. The first worry is pretty
44:15simple, that is how fast can we do the
44:18calculation or how fast can we compute?
44:20The second worry can be can we do
44:22something some processes in parallel in
44:25order to show the data faster to the
44:27user. You may have seen a lot of systems
44:29in which in parallel the image is being
44:32processed and you are able to move
44:34further with the application. Let the
44:36image process and the meanwhile you are
44:38moving to the other features of the
44:40application. The next issue can be how
44:42can we reduce the computational cost?
44:46And also as a system designer, we can
44:48also think about can we use GPU instead
44:51of CPU? So, these are the common worries
44:54of a computer intensive application
44:56where the data is not much, but the
44:59processing is the king. Let me also take
45:02a good example of a computer intensive
45:04application. So, in order to create a
45:07simulator machine, it is very important
45:09for the simulator to work exactly how
45:12the actual machine works. So, think
45:15about a scenario that our country is
45:17hiring a lot of pilots every year and we
45:20can't spend too much on the actual
45:23aircrafts when the pilot doesn't know
45:25how to ride it or how to fly it.
45:28In order to train them, we need to give
45:31them simulators machines and on which
45:34they train themself first and then sit
45:36on the actual plane. So, now in
45:38simulation machine, our common worries
45:41or the task which we are going to have
45:43is can we do anything in parallel again?
45:46Can we use GPU instead of CPU? Again,
45:49how can we reduce the cost of our
45:50simulator? Also, we need to find a way
45:53to gather a lot of good algorithms in
45:56order to do the task frequently. Now, at
45:59this point I think we are very clear on
46:01how our data intensive applications are
46:03different from computer intensive
46:05applications and why we need to put our
46:08focus on computation on different
46:10algorithms on GPU or CPU in order to
46:13make a computer intensive application
46:15works because the data is very low and
46:17in data intensive application if we
46:19start focusing on GPU and CPU there will
46:22not be any big changes because the issue
46:25lies in the database network calls
46:27caching algorithms or maybe server. So
46:30in order to fix them we need to put our
46:33effort into the right category into the
46:35right components so that our application
46:38works seamlessly. And why this is
46:39important? Because if we put our efforts
46:43into the wrong components our components
46:45are not free they are going to cost us
46:47money and if we put the money in the
46:50wrong place and not getting any help in
46:52order to solve our issue it is going to
46:55be a bad system design for the entire
46:57game. Now when we talk about data
46:59intensive or computer intensive
47:00applications we often think that these
47:03two are very separate applications. But
47:05in today's time we live in the
47:07environment of multiple applications and
47:10each application performs multiple
47:12tasks. So that means our data
47:14intensiveness or the computer
47:16intensiveness of the application can
47:18also depend on the feature we are
47:20working in. For example we have YouTube
47:22right? YouTube is data intensive for
47:25serving the videos. There are a lot of
47:28videos in YouTube environment and you
47:30get the videos and we can say that it is
47:33computer intensive when it comes to the
47:35recommendation. Because in order to get
47:38the recommendations we have to get what
47:40you are watching right now. So I think
47:42it is pretty sorted now that in order to
47:44fix a particular issue you need to first
47:47think whether the issue which we are
47:49facing is computer intensive or data
47:52intensive and then you get into the
47:54components and fix that. There is a
47:56trick to understand whether the feature
47:58is data intensive or compute intensive.
48:00That is, if the time is lost in data
48:03movement, probably it is data intensive
48:05application. Or if the time is lost in
48:08the computation, it is probably a
48:10compute intensive feature or the task.
48:13This one distinctions save you a lot of
48:15money, time, and complexity. In order to
48:19discuss our requirements, we divide the
48:20requirements into two categories. One is
48:23functional requirement and the another
48:25one is non-functional requirement. So,
48:27let's go to our screen and let's discuss
48:29this. Functional requirement says,
48:31"Please define all the points which you
48:33are building, all the features which you
48:35are building, all the working which you
48:37are building." That means, if we define
48:40every feature that comes under the
48:42functional requirement. So, let's
48:44understand functional requirement by
48:45taking an example of any e-commerce
48:48application, let's say Amazon. So, what
48:51can be the functional requirements of
48:53Amazon application? That means, we are
48:55defining each and every feature which we
48:57see on Amazon. So, let's say on Amazon
48:59application, a user can register
49:02themself. User should also be able to
49:04log in. So, let's write that. After
49:07login, user should be able to see the
49:08products. Also, user can search the
49:11products or filter them. Let's write the
49:13searching and filtering into two parts.
49:15So, search the products and user
49:18can also filter the products. After
49:20filtering, searching, user should be
49:22able to add any product to the cart.
49:24After adding any product to the cart,
49:26user should be able to get some
49:28promotions or get some discounts, right?
49:30So, they should be able to apply the
49:32coupon codes to get the discount. And
49:34once all this done, user should be able
49:36to place the order. After placing the
49:39order, user should be able to do the
49:40payments, maybe. And once the item is
49:43placed, once the order is placed, user
49:45should be able to track that order. So,
49:47all of these points are the functional
49:49requirements of Amazon or any e-commerce
49:52application for that matter. In which we
49:55define all the functionalities, all the
49:57actions which user can take, all the
49:59working of the application is defined
50:01under functional requirement. So, if we
50:04have to write this, what is functional
50:05requirement again? Functional
50:07requirements means all the features
50:09which you are going to have in your
50:10application are the functional
50:12requirements. Now, let's move forward to
50:14the non-functional requirements. For
50:17non-functional requirements also, let's
50:18start with the example of Amazon only.
50:21Let's say the first non-functional
50:23requirement is that on our Amazon site,
50:26we have
50:27approximately 1 million users. So, that
50:30means our system should be able to
50:32handle 1 million daily active users.
50:35Now, in order to give our users a good
50:37experience, we can say that the response
50:40time should be less. But, in
50:42non-functional requirements, we have to
50:43define how less.
50:46So, let's say for Amazon application,
50:48the response time should be less than
50:51200 milliseconds for each request. Now,
50:54our application is built and is running,
50:56that means our application can't handle
50:58failure. But, that is not possible,
51:00right? So, we should define up to how
51:03much is our availability of our system.
51:05That means for how much time our system
51:08will be available. That are defined
51:10under SLAs and SLOs. So, we have to
51:13define them. That for 1 year, our system
51:16downtime should be this much amount
51:18only. And for 99.9%
51:21time, our system should be up. That is
51:23defined under availability. After
51:26availability, we don't want our data to
51:28be flowing easily, so we want to encrypt
51:30our data. And let's say on any sale day,
51:34let's say Black Friday sale or Diwali
51:36sale or Holi sale, in those times our
51:39normal users can go up to 10x. So, our
51:42system should be able to handle that
51:44much traffic also. So, let's write that
51:46down. With this, our system should be
51:48also able to handle the faults. Because
51:51there are going to be faults in the
51:53system. No application is perfect so
51:55far. Every system have their own faults,
51:58have their own downtime. But we need to
52:00see how can we track them and how can we
52:03fix them as fast as possible. So, that
52:05is we need to make our system fault
52:08tolerant. So, with this example of
52:10Amazon, we get to know that our
52:12functional requirement are the features
52:14of the system that we can say what our
52:18system is going to do. And with
52:20non-functional requirements, we define
52:22how our system is going to perform. So,
52:25these are the specific non-functional
52:27requirements for Amazon. If we have to
52:30write it in a generic way, there are
52:32some generic terms which we can write.
52:34So, we can talk about scalability. Let's
52:37say our current configuration of server
52:39is reaching to a point where it is not
52:41able to handle the kind of traffic it is
52:43getting. So, now in order to scale, will
52:46you scale it horizontally or vertically?
52:49That will be taken care under
52:51non-functional requirements. Apart from
52:53that, as we have discussed, availability
52:55of every system will be defined under
52:57the non-functional. As we have already
52:58discussed, that means our system uptime
53:02will be calculated here.
53:04Which is defined under SLAs and SLOs.
53:08So, in these agreements, it is already
53:10defined that, let's say we are using
53:12Amazon server in order to deploy our
53:14application, then Amazon will give us
53:17some contract that we will be down up to
53:19this time. And apart from that, you will
53:22not see any issues. Now, in those cases,
53:24if we see any issues, let's say for a
53:27day, Amazon says that we will be down
53:30maybe for 5 minutes maximum. But then,
53:32if Amazon fails to keep that promise or
53:35that agreement, the companies which are
53:37using the Amazon service can sue them.
53:40Because the Amazon services have given
53:42us the SLA's in writing that the
53:45services will not be down after certain
53:47point. So, availability plays a huge
53:49concern there. Next, we have
53:51reliability. In reliability, we can say
53:54that our system should be reliable. That
53:56means there should be no data loss in
53:58our system. After reliability, comes the
54:01performance. Under performance, we are
54:03going to define how our system is going
54:05to work, how much latency can we feel in
54:08the system. What is our P95? What is our
54:11P90? What is our P99? These all things
54:15are defined under performance. So, all
54:17the words which I have said in this
54:19particular video, we are going to cover
54:21each and every topic in details in the
54:23coming videos. So, don't worry about
54:25this if you don't get it now. After
54:27performance, we can jump to security. In
54:29security, we can have features like
54:31authentication, authorization, and
54:34encryption. With security, we are also
54:37dealing with a lot of code. That means
54:39we can say our code should be in perfect
54:41modules so that each code or each chunk
54:44of code can use different APIs or
54:47different modules in order to work in
54:48efficient way. After this, we have last
54:51but not the least requirement, that is
54:53observability. Even if our code is
54:56pushed to production, there are a lot of
54:57use cases which are handled after that.
55:00Because we don't know the exact behavior
55:02of users, that how they are going to use
55:05it. So, we need to keep track of all the
55:07monitoring tools, all the tools which
55:09are going to track the user behavior on
55:11our application. So that we can improve
55:14our system and also we will be able to
55:16track if there are any bugs and solve
55:18them. So, let me write monitoring and
55:20logging. So, this is all about
55:22functional and non-functional
55:24requirements. I hope you all get it. But
55:27in order to completely get it, we all go
55:29through a lot of applications on a
55:31day-to-day basis, right? We may be
55:32scrolling through Instagram, maybe
55:34watching YouTube, maybe watching
55:35Netflix, or Amazon Prime, or purchasing
55:38anything from Flipkart, Amazon, or any
55:40other application e-commerce platform,
55:42or we may be scrolling through our
55:44WhatsApp messages. Now, I want you,
55:47while using your application, just sit
55:49back for a few minutes and think about
55:51all the functional features which you
55:53are working, or all the functional
55:55requirements which you are using, and
55:58all the non-functional requirements
55:59which the app must have configured or
56:02thought of while creating that
56:03applications. Also, comment down the
56:05application on which you worked on, and
56:08write down three to four functional and
56:10non-functional requirements. That will
56:12help you and me also in order to
56:14understand that we are learning on a
56:16similar pace.
56:17How does our browser know which webpage
56:20to hit? Do they know by domain name, or
56:22do they get these things through IP
56:24addresses?
56:25Let's find out. So, whenever on our
56:28browser or on our machine, whenever we
56:31write any address, let's say
56:33telesco.com, it is going to redirect us
56:36to the telesco page, which is our
56:39homepage. Maybe some banners here, maybe
56:41some courses section here.
56:44It is like this only. Now, how do our
56:47browser figure out which page to show?
56:50Because, as humans, we communicate
56:52through names, but systems don't
56:54communicate through names. In order to
56:56establish the communication between one
56:58system to another system, we need IP
57:01addresses. So, that means there should
57:03be some place in between or some system
57:05in between our browser or our OS through
57:09which we are going to get the correct IP
57:11addresses of each and every site. So, we
57:15will send telesco.com, and in return we
57:18will get some IP addresses. So, this can
57:20be the IP address of telesco. I'm not
57:22exactly sure about the IP address, but
57:24yeah. Like this, our DNS works.
57:27So, DNS basically stands for domain name
57:31system. Domain means any specific URL or
57:34any specific domain. Domain is this
57:36only, telesco.com. There can be multiple
57:39domains, telesco.net, google.com,
57:42facebook.com, whatsapp.com, .web I
57:44think. But yeah, you get the point.
57:46These all things are domain. And what is
57:48subdomain? If I write any subdomain,
57:51let's say docs.telesco.com
57:55or any other subdomain, let's say
57:57course. So, they both are subdomains of
58:00telesco.com. Where telesco.com acts as
58:03an umbrella and under which we can
58:05create multiple subdomains if and when
58:08required. So, these are the domain and
58:10subdomains. But mind it, the machines,
58:13the computers doesn't communicate with
58:15each other through these domain names.
58:17So, they need IP addresses. Let's figure
58:20out ways on which our system can handle
58:22the IP addresses. Let's say we are
58:24building a browser. Why do we need DNS?
58:27Why do we need another system
58:30for maintaining the domains? We can
58:32basically install or store all the
58:35domain name list on our browser only.
58:37Now, is this even possible? Let's say if
58:41we have only two or three websites,
58:43maybe 10 websites, we can store their
58:45names, even 100 also. But the current
58:48number of domains which exist in our
58:50world is more than 350 million. And as a
58:53browser, browser doesn't know which
58:56sites I'm going to use, whether I'm
58:57going to use Stack Overflow one day and
58:59Gmail the other. So, we can't store all
59:02the 350 plus domains into our browser.
59:05That will crash our system. So, two
59:07reasons because of which we can't store
59:09the entire domain list on our browser
59:12are first thing is it will get heavier.
59:15And to store such amount of information,
59:17we need a high storage browser. So, that
59:20will also impact the performance of the
59:21system. Now, the other point is what if
59:25the IP changes after some time? What if,
59:28let's say, I am running any site,
59:30teleschool.com, I have purchased my
59:33domain from maybe GoDaddy, and tomorrow
59:35I decide to discontinue my service from
59:37GoDaddy, and I'll move to Google
59:40Domains. So, I'll purchase or renew the
59:42domain from there. In that case, my IP
59:46can be changed. And if it restores, I
59:48need to reassure that in all the
59:50browsers where teleschool.com is
59:52running, I need to update them. I need
59:55to send them some update. So, through
59:57this we can estimate that it can't be
59:58stored in one browser. And also, it
1:00:01can't be stored in a single server,
1:00:03also, because it will also get heavier.
1:00:05There are more than 350 million domains.
1:00:07That means, if we are going to store it
1:00:09in a tabular manner, so the here will be
1:00:11the domain name, and the corresponding
1:00:14IP addresses accordingly. So, here we
1:00:16will have any domain name such as
1:00:18google.com, and here we will have the IP
1:00:20address, 1.2.3.4,
1:00:23for example.
1:00:24So, by this, we will create the entire
1:00:26list. This is not possible for a single
1:00:28machine to handle, because if that
1:00:30machine breaks, then the entire system,
1:00:33the entire internet will break. Anyone
1:00:35in the world will not be able to use any
1:00:38internet services or any web pages for
1:00:40that matter. No APIs will hit, because
1:00:43it all depends on the DNS. So, one thing
1:00:46is sure, we need a certain kind of
1:00:47system in order to fulfill this
1:00:49requirement. That's why we have one of
1:00:51the most beautifully designed system,
1:00:53DNS. Let's start from the high level.
1:00:56So, this is our machine, which is going
1:00:58to use some internet service provider,
1:01:01and under this service provider, we have
1:01:03something called as DNS resolver. So,
1:01:05this DNS resolver is responsible for us
1:01:08to getting the correct IP of any
1:01:11websites or any domain which we are
1:01:13trying to process. In order to
1:01:15understand this clearly, let me take
1:01:16this and put it in a side, so that I can
1:01:19draw more things onto our screen. So,
1:01:22the first call it is going to make is to
1:01:26our root server. Now, there are 13 root
1:01:29servers
1:01:30in this entire world. That means there
1:01:33are 13 companies who own 13 web servers
1:01:37in this entire world. They are not
1:01:39physically 13, but they are categorized
1:01:41into 13. So, that means out of these 13,
1:01:44we are going to hit one of them and get
1:01:46the response. These root servers are
1:01:48typically named from A to M like this.
1:01:51Again, from this A to M, they are owned
1:01:55from various companies. So, you can see
1:01:57the complete list of the root servers
1:01:58with the companies which own that root
1:02:01servers on the screen. You don't have to
1:02:03remember all of them. You just have to
1:02:05see and understand that these are the
1:02:07service providers of the root servers
1:02:09from which we are going to get some
1:02:11information in order to process our
1:02:13domain. Now, let's come back to screen.
1:02:16As discussed, we were searching for
1:02:18telesco.com. Also, I can remove this
1:02:21now. Now, when we are searching for
1:02:23telesco.com, the root server doesn't
1:02:25know anything about telesco.com, but it
1:02:28knows about the TLDs which are top level
1:02:31domains. What is top level domain? If I
1:02:34talk about .com,
1:02:37this is our top level domain. .com,
1:02:40.net, .gov, .in, .uk, .us, .education
1:02:46maybe .edu, we use them. These all
1:02:49domains are the top level domains of any
1:02:51website. So, that means if we need to
1:02:53find out where telesco.com is, we first
1:02:56need to know which server is handling
1:02:58all the .coms. So, in order to do that,
1:03:01our root server will give the response
1:03:04that okay, you can go to one of the TLDs
1:03:07which is handling the top level domain
1:03:10for .com and the root server will return
1:03:12the IP address of that. Maybe this is
1:03:14the IP address and from now, we know
1:03:17that we are going to hit any TLD,
1:03:20top-level domain for a .com. Now, from
1:03:23this TLD, we are again not going to get
1:03:26the complete IP address of the site. We
1:03:29are going to get the proper server or
1:03:32the name server or the authoritative
1:03:34servers which are managing the all the
1:03:36IP addresses for our domains. Let's say
1:03:39this is the IP address of our
1:03:41authoritative name server. And from
1:03:43this, we are going to make another call
1:03:45which are our authoritative name
1:03:47servers. And from here, we are going to
1:03:50actually get where our telesco.com
1:03:53resides, the IP address, which was
1:03:5519283841.
1:03:57And once this is captured through our
1:04:00browser, the IP, then it is going to
1:04:03make the call to telesco.com server and
1:04:06it is going to get the web page which is
1:04:08desired for. I get it this can be a
1:04:10little confusing at start, so let me
1:04:11reiterate it for once.
1:04:13So, whenever we click on any site,
1:04:16whenever we want to find any site, let
1:04:18it be telesco.com, it is first going to
1:04:21our service provider, internet service
1:04:24provider. Also, you can see uh
1:04:27it can go through router and router can
1:04:29also have DNS resolver. So, from
1:04:32internet service provider which have DNS
1:04:34resolver, this component is going to
1:04:37resolve all our queries for us and
1:04:39ultimately will give us a perfectly fine
1:04:42working IP address for telesco.com or
1:04:45any other site for that matter. So, the
1:04:48first step is it will go to the root
1:04:50servers. What is root servers? There are
1:04:5313 companies who own these root servers
1:04:57who doesn't know the IP address of your
1:04:59site directly, but knows which TLD to
1:05:02follow. So, from root server, it is
1:05:05going to check what is your
1:05:08TLD, top-level domain. And in this case,
1:05:11it is .com. Now, as it is dot com it is
1:05:14going to get the IP address of the TLD
1:05:17which is handling the dot com domain. So
1:05:20after this first call now we are going
1:05:22to call the TLD which we get from the
1:05:24root server and from this also we are
1:05:27not going to get the complete IP address
1:05:29of telesco. We are going to get on which
1:05:32name server we are going to hit to get
1:05:34the complete IP address of telesco.com.
1:05:37So from here we are going to get the
1:05:39authoritative name servers IP and
1:05:42accordingly we are going to hit our
1:05:44third and final call to our
1:05:46authoritative name servers. Our
1:05:48authoritative name servers are mostly
1:05:51can be configured in GoDaddy or
1:05:53Hostinger or any other service providers
1:05:56in your current application. And from
1:05:58these authoritative name servers we are
1:06:01going to get the IP address of
1:06:03telesco.com. Now in order to click one
1:06:06side we have to do these three
1:06:08operations. This can be heavy, right? So
1:06:11this is only done first time and the
1:06:13next time when you click on anything it
1:06:16basically takes the value from cache.
1:06:18Now cache can be stored in three
1:06:20locations here or more than three if you
1:06:22think about it, but three are definite
1:06:25locations. The first is the DNS resolver
1:06:28can have the cache to have all the
1:06:31common IP addresses which we are going
1:06:33to take or the all the common domains
1:06:35which we are trying to hit. It can store
1:06:38it here. Also on our system we have two
1:06:41things. One is OS and one is browser. In
1:06:44both of these areas we can basically add
1:06:46that domain and the IP address in order
1:06:49to get the details fast. So browser also
1:06:52maintain that cache OS level also we can
1:06:55basically maintain the cache and on our
1:06:58DNS resolver site also a cache is
1:07:00maintained in order to get the details
1:07:03fast. Now when we are at this topic let
1:07:05me tell you about one more thing, that
1:07:07whenever we create domain name systems
1:07:09like this dogs or subdomains, these all
1:07:13entirely creates a zone
1:07:15in the authoritative name server. That
1:07:18means telesco.com including all the
1:07:21subdomains. So, one zone can contain
1:07:23multiple domain list, which will include
1:07:26only the domains specifically to that
1:07:29particular main domain. Okay? And
1:07:32through this it is easier to get to the
1:07:34main domain. So, in this case, whenever
1:07:37we are hitting the root server, we are
1:07:39getting the IP of TLD, again hitting the
1:07:41TLD, getting the IP of authoritative
1:07:44name server. And in authoritative name
1:07:46servers, we can have different zones
1:07:49attached to different domains.
1:07:52And in this zone, if it is telesco zone,
1:07:55in that case, all the domains which are
1:07:57associated with telesco.com will be
1:07:59here. So, if instead of telesco.com, if
1:08:02we are hitting courses.telesco.com,
1:08:04and from this, the authoritative name
1:08:07server will get that this is our telesco
1:08:09zone. And in telesco zone, we will get
1:08:12the courses.telesco.com
1:08:14IP address also. So, yeah, this is it
1:08:17for DNS for now. I hope you understand
1:08:19it. If you get it, let me know in the
1:08:21comments. If you have any queries also,
1:08:23let me know in the comments. Have you
1:08:25ever wondered, if you see Zomato, if you
1:08:27see Uber, if you see Ola, if you see
1:08:30Rapido, and all these applications, also
1:08:32Swiggy, they all have an inbuilt map.
1:08:36But, did they create their own map in
1:08:38their applications, or do they use the
1:08:41existing Google Maps in order to do
1:08:43that? Now, that is possible only through
1:08:46APIs. So, Google Maps present some APIs
1:08:50to other applications which they can
1:08:52use. Now, in order to understand APIs in
1:08:54detail, let's dig into this video and go
1:08:57to our screen. If we think about API,
1:09:00the API basically stands for application
1:09:03programming interface. Now, what does
1:09:06this mean? Suppose this is our
1:09:08application.
1:09:09Any application will work. Let's say
1:09:11this is a movie application.
1:09:13In which we have all the movies, plus we
1:09:16have all the ratings, all the reviews of
1:09:19the movie. Like IMDb or something, okay?
1:09:22Like Rotten Tomatoes or something. So,
1:09:24we are already capturing all the details
1:09:26which includes a movie like latest
1:09:28movie, latest hits of 2000, 2010, 2020,
1:09:32everything. Now, we already have this
1:09:34amount of data which is stored in our
1:09:36database and our application is already
1:09:39working on that. Let's say now in any
1:09:43other corner of the world, someone is
1:09:45trying to create one application based
1:09:47on the data which is already captured in
1:09:50this app. Now, they have two options.
1:09:53Either they can create their own engine
1:09:55like this, their own application where
1:09:57they will again curate all the ratings,
1:09:59curate all the reviews, and curate all
1:10:01the data. But now, where are they going
1:10:03to curate this from?
1:10:05For this, every application leaves some
1:10:08end points which can be used by another
1:10:10application. Now, if
1:10:13for our application or for this
1:10:15developer application, if they want to
1:10:17use rating of some movie application,
1:10:19they can directly call the APIs of this
1:10:22application and through which they will
1:10:24get the proper information which is
1:10:25required for them. Now, like this, this
1:10:28developer or this application don't have
1:10:31to create their own application for the
1:10:33task which has already been done.
1:10:36So, they can use the application data
1:10:38directly. But again, can't we directly
1:10:41give access to our database? This can be
1:10:44dangerous, right? Because then this
1:10:46application again have to handle a lot
1:10:48of scenarios based on the database
1:10:50queries, plus they can also delete some
1:10:53important data in this database which
1:10:55will affect the other applications which
1:10:58are using the same content. Also, there
1:11:00are some added functionalities. Let's
1:11:02say we are giving an option to write a
1:11:03review again. So, in this we have
1:11:06already handled that case through some
1:11:08or the other API. So, instead of
1:11:11creating a new endpoint in this
1:11:13application, we can directly access the
1:11:16endpoint of the other application, which
1:11:18is going to take our review also.
1:11:21So, in this case, this application saves
1:11:23a lot of time because they are using
1:11:26another application, the APIs of another
1:11:28application through which they are going
1:11:30to do the same work. Now, in this case,
1:11:33if this application wants to add some
1:11:35data into their database also, they can
1:11:37easily do this. So, this is one use case
1:11:40of creating an API or using APIs of
1:11:42other application. Also, there can be a
1:11:45case where you're creating an
1:11:47application and in the backend you are
1:11:50exposing the APIs which can be used by
1:11:53your front end. So, front end can be a
1:11:55web application or even a mobile
1:11:57application. Can be both also. Let's say
1:12:00we are creating some backend and from
1:12:02for that application we are also
1:12:03creating front end maybe using React or
1:12:05something and backend using Swift or
1:12:08something. In both of these cases, these
1:12:11languages, the React and Swift, both are
1:12:14capable of handling APIs. So, they don't
1:12:17care about which language did the
1:12:19backend use in order to provide them the
1:12:22API. They will directly call the APIs
1:12:25and use the information which they are
1:12:26trying to use. So, this is another
1:12:28scenario where there are no two
1:12:30applications, there is only single
1:12:32application which is divided into front
1:12:34end and backend part and using the data
1:12:37which backend is providing. Again, in
1:12:39this case also, you can think that they
1:12:42will use the database directly, but it
1:12:44is restricted and prohibited for the
1:12:46security of data which we have already
1:12:48discussed in the first case. So, with
1:12:50this we understand the core
1:12:52functionality or usage of the APIs.
1:12:54Number one is if you want to give access
1:12:57to some other application, and number
1:12:59two is if you want to give access of the
1:13:02endpoints or the APIs to our front end.
1:13:05Now, this both can also happen at the
1:13:07same time because it is up to us how do
1:13:10we want to expose our APIs. Some
1:13:12applications or some backend basically
1:13:15restrict the APIs to be used through
1:13:17their front end applications only. And
1:13:19if you want to make them open, you can
1:13:21make them open so that other application
1:13:23can also use the same API. Now, let's
1:13:25move forward to the type of APIs. The
1:13:28first type of API is called as REST API.
1:13:31If you are a developer, you already are
1:13:33using this. Also, if you are creating
1:13:35projects, you might already have created
1:13:37them or use them in your application.
1:13:40Now, REST basically stands for
1:13:43representational state transfer. REST is
1:13:46one of those APIs which you will see in
1:13:49most of the application nowadays because
1:13:51of its easiness, its structure, and its
1:13:53ability to easily maintain a large
1:13:55amount of data with low volume.
1:13:58So, that's why we use REST. Mostly, in
1:14:01REST we use JSON,
1:14:04which is JavaScript Object Notation,
1:14:06which is a way or a format through which
1:14:08we will send or retrieve the data. It is
1:14:11a easy to use format, that's why we are
1:14:13sticking with this for this today's
1:14:16video, and we are going to cover this in
1:14:17details in a minute. Also, we have some
1:14:20other types, that is SOAP. SOAP
1:14:24basically stands for Simple Object
1:14:26Access Protocol. This is also one way of
1:14:28handling the data across applications,
1:14:31across different platforms, and SOAP
1:14:33basically use XML formats in order to
1:14:36transfer the data.
1:14:38XMLs are replaced by JSON because XMLs
1:14:42were really bulky in nature because in
1:14:44order to create every object or every
1:14:47array, we have to mention the attributes
1:14:50again and again, which is solved by
1:14:52JSON. So, that's why we prefer JSON over
1:14:56XML any day in today's time. But, the
1:14:59SOAP or the XML was famous back then.
1:15:02So, that means there are a lot of
1:15:04applications which are still using XMLs.
1:15:07Why? Because there are legacy
1:15:08applications. They are built way earlier
1:15:11when JSON was introduced and still are
1:15:14using XML. So, in legacy system, if the
1:15:17APIs are created and exposed using XML,
1:15:21that means
1:15:23in order to make our system work, we
1:15:25also need to know about XMLs so that we
1:15:28can integrate those APIs into our
1:15:30system. Also, you can use some
1:15:33middleware application where the data
1:15:36will be taken in the form of XML and
1:15:38will be converted into JSON and your
1:15:42application can use that data
1:15:43afterwards. So, that's why if you are
1:15:46working with a legacy system, it is
1:15:47preferred to understand the XMLs also so
1:15:50that you can convert them in JSON or you
1:15:53can work them without converting them as
1:15:55well. So, after SOAP, let's jump to the
1:15:57third one, which is GraphQL. So, GraphQL
1:16:01is also used widely across many
1:16:03applications, many platforms. So, the
1:16:05basic thing in GraphQL is GraphQL
1:16:08basically says that I'll provide a
1:16:11single endpoint, only a single endpoint,
1:16:14and based on that, you can send
1:16:16whichever query you want. So, in FE,
1:16:19from FE side, we will not hit multiple
1:16:22endpoints, but we will send a request as
1:16:25a query. That's why the GraphQL stands
1:16:28for graph query language. So, GraphQL
1:16:31also have a query language that is
1:16:33similar to SQL. In SQL also, we have
1:16:35multiple queries from which we can do
1:16:37our things.
1:16:38In this also, only one point is exposed
1:16:41as I told earlier and using that only
1:16:44the front end now can send multiple
1:16:47queries and access that particular
1:16:49endpoint and get the data which they
1:16:51want. So, this is the core concept of
1:16:53GraphQL. So, as I said, GraphQL is also
1:16:56present in our today's time also. So,
1:16:58there can be a chance that you learning
1:17:00GraphQL and working on it. The other
1:17:03type of API is gRPC. Here, the RPC
1:17:07stands for remote procedural calls and
1:17:09for G some may say that G stands for
1:17:12Google because it is created by Google,
1:17:14but it is gRCP
1:17:18remote procedural calls only. So,
1:17:21instead of using XML and JSON, we have a
1:17:23new format here which is called protocol
1:17:25buffers. It is very much efficient than
1:17:28JSON and XML combined. So, that means
1:17:31the size of protocol buffers are usually
1:17:33very small than XML or JSON. So, that
1:17:36will enable the data to transfer faster.
1:17:39So, because of this only Google created
1:17:41this and uses this.
1:17:43So, this is small in size and faster to
1:17:47transfer. In today's applications where
1:17:50we have microservices, right? So, in
1:17:52microservices, this is our entire
1:17:55application and let's say our
1:17:57applications is divided into multiple
1:17:59applications which is combining the data
1:18:03of their endpoints through each other.
1:18:05Let's say these are the connections and
1:18:08through this they are going to provide
1:18:10the actual API to the outer world. Now,
1:18:12for this communication between these
1:18:14microservices, we often use gRPC. Why?
1:18:18Because internally at least the
1:18:21communication should be faster to
1:18:22provide the relevant information in a
1:18:25low latency. This will also help us
1:18:28having multiple microservices and having
1:18:30various kind of communications between
1:18:32them before giving the actual data to
1:18:34the other application or the front end.
1:18:37Now, let's jump to the last one in our
1:18:39list today, which is WebSockets.
1:18:42WebSockets are also used in today's time
1:18:44and today's application for various
1:18:46purposes. For every notifications, if we
1:18:49see, WebSockets are used. In order to
1:18:51maintain a chatting stream, WebSockets
1:18:54are used. Wherever you need some
1:18:56real-time connections, WebSockets are
1:18:58used. So, its architecture is slightly
1:19:01different from the other services. In
1:19:03other services, front end or the other
1:19:05application will place some request to
1:19:08the application and then they will
1:19:10provide the response. But, in
1:19:12WebSockets, whenever front end creates a
1:19:15request, a channel is created. Now, once
1:19:18the channel is established, then the
1:19:20conversation can be lead through back
1:19:22end also. Whereas, in other forms, only
1:19:25front end or the other application,
1:19:27which is trying to access the
1:19:28information, they send the request and
1:19:30get the request. But, in this case,
1:19:32since the back end also can initiate the
1:19:35conversation, that means it can also
1:19:37send some or the other information by
1:19:40itself. Those information can be the
1:19:43chat or the notifications, which is very
1:19:46helpful for front end to get. Because,
1:19:48if this channel is not there, the front
1:19:50end have to constantly ask the back end
1:19:53whether there are some new notifications
1:19:55or not or whether the chat is there or
1:19:57not. But, once the channel is maintained
1:19:59through WebSockets, it is easy to
1:20:01navigate message from back end to front
1:20:04end and front end to back end as well.
1:20:06With this also, if you have played
1:20:07quizzes on our Teleschool platform only,
1:20:10Teleschool channel, in which you may see
1:20:12an application which Naveen sir presents
1:20:14in order to share the quiz with you all,
1:20:16you use that application in order to
1:20:18give the responses. Now, those responses
1:20:21or the marks are calculated based on the
1:20:23response time and the correctness of the
1:20:25answer. Now, those connections are also
1:20:28maintained through WebSockets. That's
1:20:30why you see many notifications or some
1:20:32GIF or something something. So, this is
1:20:34about web socket and with this I would
1:20:36like to conclude this session because it
1:20:38is going to be a long session and it is
1:20:40better to understand these things in
1:20:42parts. So, these are the most used five
1:20:46type of APIs which we have. Now, in
1:20:49order to understand them briefly in the
1:20:51next video, I'm going to talk about
1:20:53RESTful APIs in which we will discuss
1:20:55the various aspects or the parts of the
1:20:58APIs
1:21:00and also see what are the
1:21:01recommendations and usage of those APIs.
1:21:04Now that we already know about RESTful
1:21:06APIs and all the other different type of
1:21:08APIs, it's time to deep dive into one of
1:21:10them. And for today's video, I have
1:21:12selected REST APIs to deep dive into.
1:21:15Why? Because it is the most used APIs
1:21:18across the world. It doesn't matter if
1:21:20you are starting a career or you are
1:21:22already seasoned, you have to work with
1:21:24RESTful APIs for sure. So, let's move to
1:21:26the screen now. RESTful APIs are also
1:21:29known as REST APIs. As we know, it
1:21:31stands for Representational State
1:21:34Transfer. What does it mean? It means
1:21:36that REST is also one format through
1:21:38which we will transfer our data from one
1:21:40end to another end. What are these ends?
1:21:43We have discussed this already. Either
1:21:45we are giving some data from front end
1:21:47to back end or vice versa. It is also
1:21:49possible that one application needs to
1:21:52get some data from some other
1:21:53application. So, in that case also, APIs
1:21:56are used and REST specifically is used
1:21:59to transfer some data from one end to
1:22:01another end. So, basically, it is a way
1:22:04of how our applications are going to
1:22:06communicate with each other. Now, before
1:22:08starting, let me tell you that in REST,
1:22:10we normally use JSON. JSON is a standard
1:22:14way of sharing the data.
1:22:16In JSON, we can have array, we can have
1:22:19object and with these two combinations,
1:22:22we can share our data in the form of key
1:22:24and value. So, let me create a simple
1:22:26JSON. Let's say this is a start of an
1:22:28object and here we have a key, let's say
1:22:32name. For value, I'm writing my name.
1:22:34With comma, we separate different
1:22:36values. So, after comma, I have to write
1:22:38some other key. So, let it be age. And
1:22:41with age, I can write any numeric value
1:22:43as well. So, as we can see, this is
1:22:45string value and this is a numeric
1:22:47value. There are more values who are
1:22:50accepted as a form of value, which is We
1:22:53have already seen string and then
1:22:55number. We can also use boolean, even a
1:22:57nested object, arrays, and a null. Null
1:23:01can also be used because if we don't
1:23:03have any value for that particular field
1:23:04directly, it is easy to say it is a null
1:23:07value. And the application which is
1:23:09using that value can take care of it.
1:23:11So, this is all about the JSON which we
1:23:13need to know. We need to know that it is
1:23:14in the form of key-value pair and what
1:23:17are the values which we can use. Now,
1:23:19let's move forward to the next part,
1:23:21which is endpoint. In order to
1:23:23understand endpoint, we have to get two
1:23:25things. One is method and the other
1:23:28thing is path. So, in order to access
1:23:30any data, we have to have some URL on
1:23:34which we will hit with that particular
1:23:36method and based on the method selection
1:23:38and the path, we are going to either get
1:23:41or pass some data to our server. Let me
1:23:43start this with an example. Suppose we
1:23:45are using HTTP as uh any site, my site
1:23:50.com. So, this is our main site and
1:23:52after that, we can put a slash and use a
1:23:55different URL. Let's say we are
1:23:57separating all the APIs in the API
1:24:00subdomain. So, APIs is there and then we
1:24:03can also segregate the APIs using
1:24:06version. So, this is version one and
1:24:08here we are going to write resource.
1:24:10Now, resource can be anything. If I talk
1:24:12about any e-commerce application, it can
1:24:14be a product, it can be coupon, can be
1:24:17user, can be anything, basically. A
1:24:19resource is an entity through which we
1:24:21are navigating and getting and passing
1:24:23the data to the database. So, this is
1:24:25the URL. The URL is called the path
1:24:28through which we are going to either get
1:24:30or pass some data. And with this, we
1:24:33need to have a method. So, for method,
1:24:36we can have a get basically. So, get
1:24:38method with this path combinedly creates
1:24:41an endpoint and through which now we can
1:24:43get some data. We expect this path to
1:24:46retrieve some data because we are using
1:24:49get. Now, there can be multiple ways of
1:24:52creating this URL. So, normally, we hide
1:24:55the domain part of it. We don't use them
1:24:58in the explanations. We only use the
1:25:01resource part. Also, we can remove the
1:25:03version also. With that, API can also be
1:25:05removed in order to understand the
1:25:07resource part directly.
1:25:09So, from now on, if I create any path,
1:25:12let's say users, it is expected to have
1:25:15all this domain name API versioning if
1:25:18it is there beforehand. So, I'm not
1:25:20writing that again and again. Cool. So,
1:25:22with that, if I write users here and use
1:25:25get method, now I'm expecting some
1:25:28response from our server. I'm expecting
1:25:31either a list or a response from our
1:25:33server. We'll come back to responses in
1:25:35a while, but this is how we can get some
1:25:37user information from our server. Now,
1:25:40let's move to the second part. In this,
1:25:42we don't want all the users, we want a
1:25:44specific users. So, to find a specific
1:25:46user, we have to provide them an ID.
1:25:48Normally, we provide them in the URL
1:25:50itself. So, it is get users and here we
1:25:54can include the ID. So, in real time, it
1:25:57can be used as users/1.
1:26:00So, if we write one, the user with the
1:26:02ID one will be retrieved. Now, with
1:26:05this, we can also add any user. So, the
1:26:07third part is
1:26:09adding a user. So, again, the URL will
1:26:12be same users and now we are adding the
1:26:14user, so we are using the method post
1:26:17here. So, in this with post, we are
1:26:20going to give some body, and in body, we
1:26:23will have some JSON which will store the
1:26:25user information which we are trying to
1:26:27create. And based on our request, our
1:26:29user will be created in our database.
1:26:31Now, once we have all the user details
1:26:33in our table, we may choose to update
1:26:35any user information, correct? So, for
1:26:38that, we use another method which is
1:26:41put. Again, the URL will be same, users.
1:26:45And with this users, we will send the ID
1:26:47of the user of which information we are
1:26:50trying to update. So, with put, we also
1:26:53have another method which is patch,
1:26:55which can also be used in a similar way
1:26:57to update the user information. Now,
1:27:00what is the difference between put and
1:27:02patch? It is simply that if we use put,
1:27:05our entire user object will be replaced
1:27:08with the new data. So, this is going to
1:27:10replace the user data. And if we don't
1:27:13want to update all the fields, we want
1:27:16to update a specific field or particular
1:27:17field, suppose username, name, age, or
1:27:20anything, so we can use patch. It can be
1:27:23used to partially update the user
1:27:25record. Let's understand this with an
1:27:27example. Let's say we have any user
1:27:30information which have ID and have a
1:27:33name and have a username, maybe age.
1:27:36This is all. So, these are all the
1:27:38values which are
1:27:40user currently have. Let's we put some
1:27:42values. So, if our user table or user
1:27:45entity have these all four values, if we
1:27:49use put to update a particular change
1:27:51only, let's say I'm going to change my
1:27:55username from Akshay to AK something.
1:28:00So, now this change will only be done if
1:28:02we again send the entire body into the
1:28:05put request. If we only send username
1:28:09like this, then all the other values of
1:28:12our entity will be updated with the
1:28:13default value. So, if we send this kind
1:28:16of data in a put request, it is going to
1:28:18replace our entire entity. So, that
1:28:20means the name, the age will be replaced
1:28:24by the default or null value. So, it is
1:28:26not recommended to use put entirely if
1:28:29you want to update your entity
1:28:30partially. In those cases, always try to
1:28:33use patch. In patch, we're going to
1:28:36again update the particular information.
1:28:38So, this is perfectly valid for a patch
1:28:41request. So, with this, let's move to
1:28:43the next part. The next kind of method
1:28:46which we use is delete. In delete also,
1:28:48normally we pass the ID like this. So,
1:28:52if we write users and with {slash} we
1:28:55write one, so that means the user with
1:28:58the ID one will be deleted. Now, this is
1:29:00the usual stuff. You will get this
1:29:02information anywhere. Now, let me talk
1:29:04about something which is nested data.
1:29:07Let's understand nested data with an
1:29:08example. Suppose you're creating a blog
1:29:11site. So, in blog site, we normally have
1:29:14our users who are going to read our
1:29:16blogs. Then, we have blog, the actual
1:29:18content on the site. And on blog, the
1:29:21user can comment. So, we have clearly
1:29:23three entities: users, blogs, and then
1:29:27comments. So, these three entities are
1:29:29interrelated. So, a user is going to
1:29:32give comment on a particular blog. Users
1:29:36can't comment if there is no blog,
1:29:38correct? So, this is the way. Now, in
1:29:41order to create APIs for this, we can
1:29:44create a users API for all the users'
1:29:47activity. So, all the users' activity
1:29:49means we can use it for get, put, push,
1:29:54delete, and patch also. Now, this is
1:29:56simple because a single entity is there,
1:29:58users, and all the operations are on
1:30:01that users only. Now, let's say we want
1:30:04to create an API on which user can add a
1:30:09comment. Okay? So, for that, what we can
1:30:11do, we can either go from the blogs
1:30:14perspective. So, every blog have a
1:30:16particular comment section, right? So,
1:30:18blogs, then here we can write ID. So,
1:30:21this ID is basically belong to the blog,
1:30:23and with blog, we can write comments.
1:30:26And if we write get here, what it is
1:30:28going to do, it is going to give us all
1:30:30the comments which are associated with
1:30:32the blogs with ID this. Correct? So,
1:30:36this is a nested relationship where
1:30:38we're trying to access comments, but we
1:30:41are going via blogs. We can also do like
1:30:44this. Suppose we are on the user's page,
1:30:46and we want to see all the comments that
1:30:48user have created. So, we can again
1:30:50create a get query
1:30:52via users, where this is the user ID
1:30:55here, and we can see comments. So, we
1:30:58are dealing with two different entities
1:31:01by creating the relationships between
1:31:02them. So, by this, we are going to get
1:31:05all the comments which are created by
1:31:07the user with this ID. So, we can go to
1:31:10comments via blogs, as well, and via
1:31:12users, as well. So, this is nested.
1:31:15Again, if you want to update any
1:31:17comment, delete any comment, we can use
1:31:20simply the comments path
1:31:22where the user can enter the ID here of
1:31:25the comment.
1:31:26And they can use it to update or delete
1:31:30that particular comment. So, here you
1:31:32can also ask me that why are we using
1:31:34this kind of nesting in URL? Why are we
1:31:36not sending the data in the request? So,
1:31:39that is also possible. We can do like
1:31:41this. We can
1:31:42go to this comments, and we can pass the
1:31:45request body, in which we'll pass
1:31:48the post ID to get all the comments
1:31:50associated with this post. This is also
1:31:52possible, but this is not recommended.
1:31:54As there is a direct relationship
1:31:56between two entities, we don't normally
1:31:58go for this body approach. We go for the
1:32:01URL approach because it is easy to
1:32:04understand also. So, when do we go for
1:32:06the body approach? So, the body approach
1:32:09is used when we are trying to filter any
1:32:12data. So, we understood two concepts
1:32:14here. First is the nesting data versus
1:32:17filtering. So, when to use which one? If
1:32:20you have a clear relationship between
1:32:22two entities and it is clean, so you can
1:32:25go for nesting. And also in filtering,
1:32:28apart from sending the data like this in
1:32:31post ID, you can also use
1:32:33the URLs like this, comments, and then
1:32:36in query parameter, you use post ID.
1:32:39Now, this is again not recommended
1:32:41because there is a direct relationship
1:32:43between comments and post. So, it should
1:32:45be a nested type of URL. So, if there
1:32:48are clear relationship, we can use
1:32:50nesting. And if the relationship is
1:32:52complex, we can go for filtering. Also,
1:32:56the filtering will be used whenever we
1:32:58are trying to do pagination or we are
1:33:00trying to filter particular records
1:33:03based on multiple ways like we can go
1:33:05for any e-commerce page where we are
1:33:07seeing different products and we can
1:33:09filter our product based on our color,
1:33:11price range, and all these things. So,
1:33:14those things normally go for query
1:33:16parameters as a URL, right? And we don't
1:33:19go for nesting there because it will be
1:33:21complex to handle a long path with
1:33:22nesting data. So, the crux is if the
1:33:25relationship is pretty straightforward
1:33:27and we will go with respect to the other
1:33:29entity, we'll go for nesting kind of
1:33:31URLs. And if there are complex
1:33:34relationships or the filtering is used,
1:33:37we'll go for the query parameters. Now,
1:33:41let's move to the next part. How do we
1:33:43pass the actual data to the endpoint?
1:33:45So, there are three ways. Either we can
1:33:47use path, so we can integrate the IDs in
1:33:50the path, or we can use some query
1:33:53parameter, or we can use body. I have
1:33:56given you glimpse of these all three in
1:33:58the previous section, but now let's talk
1:34:00about this specifically. So for path, it
1:34:03is very specific that we will only pass
1:34:06the recommended IDs or maybe slugs or
1:34:09maybe that particular unique identifier
1:34:12only. So this is unique identifier. It
1:34:16can be ID or slug. Slug is basically a
1:34:19short form of that particular post. If
1:34:22you are using any blog site, so let's
1:34:24say the blog site the blog is about what
1:34:27is Java and in slug you can see
1:34:30something like blog /what is Java like
1:34:34this. So this is our slug. Again, this
1:34:37slug will be unique throughout our
1:34:39blogs. So the name of the URL I have
1:34:42also written blogs, it is wrong.
1:34:44Normally we address the URL in the form
1:34:47of plurals. So it is going to access in
1:34:50multiple areas, multiple scenarios. So
1:34:53normally we don't go for blog, we go for
1:34:56blogs like this. Cool. Now for query
1:34:59parameters, whenever we are filtering or
1:35:02maybe sorting, we can go for query
1:35:04parameter. Suppose we are again
1:35:06scrolling through our blogs and in blogs
1:35:09we can write like sort ASC or we can
1:35:13assign some numbers also. So ascending
1:35:15means sort ascending maybe by date. So
1:35:18whichever date they are created, they
1:35:20will be sorted by that. Or maybe we can
1:35:22use DESC for decreasing order. So that
1:35:26the latest post will be pop up first.
1:35:28With this again we can use the query
1:35:30parameter for filtering. So maybe we can
1:35:33use blogs again here and with that we'll
1:35:36pass query parameter. So this is Q for
1:35:39maybe query search or search step. So
1:35:42anyone with is searching for Java and it
1:35:45will give us a list of blogs for Java or
1:35:49which have Java in their name or their
1:35:51content or their category. So, this is
1:35:53all about query parameters. Now,
1:35:56whenever we pass any information in
1:35:58query parameter and path, those
1:36:00informations are going to be exposed,
1:36:02right? So, that means we can't pass any
1:36:05sensitive information into query
1:36:07parameters or path. So, for that we have
1:36:10body. So, let's say we have a login
1:36:12path, and now we can pass username and
1:36:15password in the body, which is not
1:36:17exposed at all.
1:36:18So, it is safe. So, the rules are pretty
1:36:21clear when we use path, query params,
1:36:24and body. Now, with this let's see a
1:36:25full request in action. The first thing
1:36:28is we will have our method. So, this is
1:36:30maybe a post method, and we are using
1:36:33some API of version three, maybe.
1:36:37For version three, we are using users,
1:36:40and then we can also pass the metadata.
1:36:42Suppose content type we can pass, which
1:36:46is application/json
1:36:49here, because we are passing the
1:36:50information in the form of JSON. We can
1:36:52also use XML, or if you have latest
1:36:55information, we also have a new format
1:36:58in town, which is
1:36:59tone. So, we can also use various kind
1:37:02of information, but because currently we
1:37:04are using JSON, so we can pass it like
1:37:06this, and with this we have our body. In
1:37:09body, we can pass anything, maybe some
1:37:11data we are trying to add, and then
1:37:13maybe username. So, like this we can
1:37:16pass the entire request or the data to
1:37:19our server. So, this is what? This is
1:37:21our method. This is the path. This again
1:37:25is metadata, and this is our body. Now,
1:37:28once we have understood the request
1:37:30correctly, it is time to understand the
1:37:32responses. So, in order to understand
1:37:34the response, first we need to
1:37:36understand the response code. So, there
1:37:38are specific codes assigned to a
1:37:41specific type of response, which if the
1:37:43user gives will clearly understand what
1:37:45they want to tell us. So, let me start
1:37:48with those status codes and then we will
1:37:50move forward. So, these are all the
1:37:52response codes which we have to know.
1:37:54200 stands for okay. So, this means
1:37:57everything is working as expected. Don't
1:37:59worry about it. Then we have 201. 201 is
1:38:03basically used when there is a new
1:38:05entity created in the database. So, this
1:38:07is created. Then we have 204. 204 is
1:38:11again saying that everything is working
1:38:13fine, but I don't have anything to
1:38:15provide to you. Let's say we are
1:38:17deleting any entity, so it is
1:38:19successfully deleted, but they don't
1:38:21have any response body to give to us.
1:38:23So, that means there is no content to
1:38:25give to us, but the request is working
1:38:28fine. Then we have 301. 301 is basically
1:38:32used for redirects and 301 indicates
1:38:35that it is a permanent redirect. And if
1:38:38the redirect is not permanent, then we
1:38:40use 302. That is temporary redirect.
1:38:44Then we will come to the 400 series. So,
1:38:47all the 400 series basically says that
1:38:49there is some issue with the request we
1:38:52are having. So, the 400 stands for bad
1:38:56request. That means some or the other
1:38:58data is not correctly mentioned in the
1:39:01body. Either they have some validation
1:39:03issue, either either they are missing
1:39:05when they are required. Either they have
1:39:07some other issues, but request which we
1:39:10are getting, the body doesn't have the
1:39:13correct information. So, in that case,
1:39:15we normally give 400 bad request as a
1:39:18response. Then we have 401. 401 is given
1:39:22when someone is trying to access some
1:39:24information for which they are not
1:39:26basically authorized. So, 401 is
1:39:30unauthorized. With that we have 403,
1:39:33which is used for forbidden. Suppose on
1:39:35an LMS, you have not enrolled for a
1:39:37course and you want to access a
1:39:39particular video or lesson part of that
1:39:41course which is not publicly accessible.
1:39:44So, in that case, you will receive 403
1:39:46forbidden because you are not allowed to
1:39:48see that particular resource. With this,
1:39:51we have 404 page not found. This is
1:39:53basically used whenever the URL is
1:39:56incorrect or trying to access some or
1:39:58the other resource which is not there
1:40:00into our system. And at last, we have
1:40:03500. So, 500 is the response which is
1:40:07given to a front end when there is
1:40:09something wrong with the back end. So,
1:40:12this is related to back end. Some or the
1:40:14other error is there in the back end.
1:40:16Maybe some syntax error, maybe some
1:40:18other error, some logic is missing, some
1:40:21data is missing, something is wrong with
1:40:23back end. So, this is internal server
1:40:26error. There are many errors which we
1:40:28don't want users to see. So, those all
1:40:32are handled by 500 because we don't want
1:40:35the user to understand what is the issue
1:40:37we are facing with our database
1:40:38connection or anything. So, we will
1:40:40create logs into our system and through
1:40:43which we'll resolve the 500 error
1:40:45issues. So, these are all the most
1:40:47commonly used response codes which we
1:40:49have to understand. So, now whenever we
1:40:51are creating any APIs, if the response
1:40:54is completely fine, we will provide 200.
1:40:57If we are creating any entity, we will
1:40:59provide 201. If we are deleting or
1:41:02performing some operations where we
1:41:04don't have to give any content or any
1:41:06data or any body in the response, we
1:41:09will use 204. Then, if the permanent
1:41:13redirection is there, we will use 301.
1:41:15If the redirection is for temporary
1:41:17basis, we will use 302. For any bad
1:41:21request in the body, we will use 400.
1:41:24For authorization, we will use 401.
1:41:28For forbidden or the content which
1:41:30requires some special access, we will
1:41:33give 403. 404 we will give when they are
1:41:37trying to access any resource which is
1:41:39not there and 500 we will give when
1:41:42there is any issue in the internal
1:41:44server. So with this, let's move to the
1:41:46next part which is response body. So
1:41:49normally in response body, what is
1:41:51allowed first we start with that. So we
1:41:54can return an array, right? Also, we can
1:41:57return an object. With this also we can
1:42:00return data as nested objects. Now in
1:42:04most of the applications whenever you
1:42:06are going through any YouTube tutorial
1:42:08or any course also sometimes when you
1:42:10are dealing with multiple responses,
1:42:13let's say the responses for this is
1:42:16normally an array, right? But it is not
1:42:19recommended to handle the response as
1:42:22array. It should always be wrapped in
1:42:25the form of an object. And if you want,
1:42:27you can use any other key for this users
1:42:31and in the value you will give these
1:42:34responses. Now these can also be string
1:42:38or an object. Normally an object only of
1:42:40all the users, but it should be handled
1:42:42like this. So this is the correct or I
1:42:45would say recommended way. So every
1:42:47response body should be an object. And
1:42:50even if we're trying to give an array,
1:42:53we have to wrap it up into an object and
1:42:56give us in the key value form. So this
1:42:58is a good practice and through this
1:42:59we'll achieve a more long-lasting code.
1:43:02Why? Let's say today we are passing the
1:43:05user details only and tomorrow we
1:43:07understand that okay, we have to add
1:43:09more fields. So we don't have to change
1:43:12much on the front end side or the
1:43:14receiving side, but we will simply
1:43:17update our response, change the object
1:43:20here
1:43:21and maybe add some other field user
1:43:24count and pass that information maybe
1:43:2729. And with this we can end our object
1:43:30here. So we can pass as many
1:43:32informations as we want, but if we have
1:43:35used a single array
1:43:37as a response, then we have to struggle
1:43:39with it and we have to change the entire
1:43:41architecture of our response. So, it is
1:43:44always recommended to pass the response
1:43:47always in the form of an object. So, let
1:43:49me write returning as array not
1:43:52recommended. Let me know in the comments
1:43:54if you already knew about this or you
1:43:56are hearing this for the first time. So,
1:43:58with this, let me create a map of
1:44:00request type and responses. So, let's
1:44:03say here
1:44:04we have request. Here are the responses
1:44:07which we are going to receive. So, if
1:44:09the request type is get and we are
1:44:12trying to access many records, so maybe
1:44:14we are trying to access users, it is
1:44:18going to give an array of records,
1:44:19right? So, it is normally going to give
1:44:23200 as a response code and going to give
1:44:26an array. Now, we understand that we
1:44:28have to not give array directly, so it
1:44:30will be wrapped in the form of an
1:44:32object. Now, the next request is also a
1:44:36get request where we want to access a
1:44:39particular object. Let's say one. Now,
1:44:43you can think that we will give the user
1:44:45information directly, but again, it is
1:44:48not recommended to give that directly.
1:44:50We will use the nested object for the
1:44:52same reason. So, in this object, we will
1:44:54use the user as key and pass on the user
1:44:58information into this object. So, this
1:45:01is the actual user object, but we are
1:45:04wrapping it into an another object
1:45:06because it will give us flexibility to
1:45:09pass some more information if we want
1:45:11to. So, let me clear this up for now.
1:45:14So, normally, we are going to get 200
1:45:16response with this kind of nested
1:45:19objects. Also, it is possible that this
1:45:22ID is not there in our DB. In that case,
1:45:26we can also give 404 response. Now, if
1:45:29we are adding anything, we will use post
1:45:31with the same URL, and normally it is
1:45:34going to give 201 response, which means
1:45:38the entity is created. And also, we can
1:45:41use 200 response if you want. But, if we
1:45:44are using 201, normally we give the ID
1:45:48or the new object as response. Now, here
1:45:53with post request, we are also giving
1:45:55the body, so it can also have 400
1:45:58issues, right? 400 bad request issue.
1:46:01And also, if the format doesn't sync in,
1:46:03it can also give 500 issue. If the data
1:46:06is coming properly and there is some
1:46:08issue in the back end, it can also give
1:46:10500 easily. So, these are most common
1:46:13response codes which you can have while
1:46:16working with post. Now, let's talk about
1:46:18delete. In delete also, we will pass
1:46:21this
1:46:22URL with some ID, and this can also give
1:46:26200 as a response. And also, if it is
1:46:29deleted correctly and we don't want to
1:46:31give anybody in the response, we can go
1:46:34for 204. If this entity is not present,
1:46:37maybe the ID they are using is one and
1:46:40we don't have any record with the ID
1:46:41one, we can have 404 or we can have 500
1:46:46if there are any dependencies
1:46:48and which is not handled correctly by
1:46:50our back end. With this, you can also
1:46:52see 401 here if you are unau- prized
1:46:55person to delete that particular record
1:46:57or you are not allowed to delete that
1:46:59particular entity, you can also get 401.
1:47:02So, these are the most common request
1:47:04responses, and with that we have also
1:47:07discussed what can be there in the
1:47:08response body. So, with this we have
1:47:10covered the entire request section and
1:47:13the response part of the REST APIs, and
1:47:16I hope the information which you get
1:47:18from this video is going to help you in
1:47:20your entire development career. Whenever
1:47:22you are dealing with REST APIs. In order
1:47:25to build any application, we have client
1:47:27on this side, right? Who is going to
1:47:30interact with either a web application
1:47:32or a mobile device to interact with our
1:47:35application. Now, with this we will have
1:47:38our server in this side. So, this is
1:47:40maybe our server. And if we keep the
1:47:42model like this only, that means every
1:47:46time we restart our server, all the data
1:47:49which user is trying to access will be
1:47:51lost. Because when server restarts, it
1:47:54clears all the data. But, the thing is
1:47:57we need to store that data somewhere,
1:47:59right? So, for that we use database in
1:48:02order to store the information which the
1:48:04user may require next time when they log
1:48:07in or see our application. Now, one
1:48:09thing is very clear that most of the
1:48:11application can't live without
1:48:13databases. Now, in order to understand
1:48:16how do we store data, we have two
1:48:18approaches. First is the SQL approach,
1:48:22and the other one is no SQL approach.
1:48:25So, SQL basically consists of RDBMS,
1:48:29which is relational database model, in
1:48:31which we will have tables, rows,
1:48:33columns, and we will connect those
1:48:35tables based on different joins and
1:48:38everything. And in no SQL, we have other
1:48:41methods. See, saying SQL and no SQL is
1:48:44like saying Java and no Java. That means
1:48:47there are various options in no SQL. We
1:48:49can have our data as in the form of key
1:48:52value. Also, we can have column. We can
1:48:55also have the data in the form of nodes,
1:48:57maybe. And we can store them in the form
1:49:00of graphs. Also, we can store the data
1:49:03in the form of document. And here, if we
1:49:05talk about SQL, we have our tables in
1:49:09place, who is going to hold our data in
1:49:11the form of entities. And there will be
1:49:13different relationships between
1:49:15different tables. Also, in order to do
1:49:18in SQL manner, we have various softwares
1:49:20like post dress or we can go for MySQL.
1:49:24Right? Like this, we can have multiple
1:49:26options here. For here also, we have
1:49:28multiple options like Cassandra or we
1:49:31can go for MongoDB. And based on this
1:49:34selection, where we are going to do it
1:49:36SQL way or no SQL way, we are going to
1:49:38build the entire foundation of our work.
1:49:41Like how our data, our important data is
1:49:44going to store in our database. So, in
1:49:47today's video, let's focus on SQL. And
1:49:50in next video, we will focus the ways of
1:49:52no SQL. So, let's start. So, SQL
1:49:56basically stands for structured query
1:49:58language. And SQL comes under the
1:50:01category of relational DB. Now, in
1:50:03relational DB, we are going to have
1:50:05multiple entities and we are going to
1:50:07establish different type of
1:50:08relationships between those entities, if
1:50:10required. So, we are going to store our
1:50:13data in the form of tables.
1:50:16So, we can loosely say that every table
1:50:19is loosely an entity.
1:50:22It can either be a user entity or it can
1:50:25be comments or it can be post, if we are
1:50:28building anything like blog site or
1:50:30something or it can be videos, if we are
1:50:32building YouTube. So, like this, we
1:50:34segregate our different entities and
1:50:37then we will build the relationship
1:50:38between them. Now, if I draw one of
1:50:40those tables, let's say we are building
1:50:42a user table. A user table can have
1:50:45multiple fields. That is equivalent to a
1:50:48user entity can have multiple
1:50:49properties. For example, a user can have
1:50:52their unique ID. A user can also have
1:50:55their first name
1:50:57and L name and maybe we also have their
1:51:00phone number. So, this is how a table is
1:51:02formed, where we have multiple
1:51:04attributes of a table. These attributes
1:51:07are stored in columns and when we have a
1:51:10complete record, let's say in this
1:51:12table, we can add a new record where I
1:51:15can add any record, let's say the ID is
1:51:18one, the name is Akshay, last name is
1:51:21Agarwal, and phone number is, let's say,
1:51:24987654
1:51:27321. So, this is my number, this is a
1:51:30complete record. Now, this record is
1:51:33called as a row.
1:51:35So, by getting any row from our table,
1:51:37we can get the entire information of
1:51:39that particular entity or of that
1:51:42particular user. Normally, for the name
1:51:44of entities, we don't go for singular
1:51:46words because it will contain multiple
1:51:48records. So, we will go for plural
1:51:51things, users. So, this is the standard,
1:51:54this is a constraint, this is not a
1:51:56particular rule, but it is safer to go
1:51:58into plural things. So, for comments, we
1:52:02can go for comments, for post, we will
1:52:04go for posts, for videos, also, we will
1:52:06go for videos. So, all these things are
1:52:09in plural. Why? Because a single table
1:52:12will contain multiple records. It will
1:52:14be easier for us to fetch the data with
1:52:17that plural name because then we will
1:52:19know that multiple entries are there and
1:52:21it is a convention to use plural things.
1:52:23So, with this, let's move to our next
1:52:25topic, which is constraints. If we are
1:52:27building any application, we can have
1:52:29multiple users who are coming with
1:52:31different backgrounds, different
1:52:32geography, and everything. So, it is our
1:52:35responsibility to make them enter the
1:52:38data correctly. We will use validations
1:52:40in form, and in database, we can handle
1:52:43them with the use of constraints.
1:52:45Because every wrong data and every
1:52:46faulty data is of no use. So, for that,
1:52:49let's dive into the constraints. So, the
1:52:51first constraint is unique. Unique
1:52:54basically stands for a unique value
1:52:57throughout the table. For example, in
1:53:00the user field, let's create the user
1:53:02table again. So, this was our user
1:53:04table, let's add one more column or one
1:53:07more attribute, which is username. Now,
1:53:09we don't want two users to share the
1:53:11same username. This is a common thing
1:53:13which we can see on Instagram also. If
1:53:16you're trying to create a new username
1:53:18and if that username is already taken,
1:53:20you may get some suggestions with some
1:53:22extra characters or you can change the
1:53:24name entirely. Similarly, for Gmail
1:53:26also, if the username is taken, they
1:53:28suggest you some more usernames with the
1:53:30extra characters. So, that means we can
1:53:32say that the username is unique. Every
1:53:35user will have their unique usernames.
1:53:37So, in order to maintain that username
1:53:39uniqueness, what we will do, either
1:53:41while creating the table or while adding
1:53:44the username field like we did, what we
1:53:46do, we add the constraint unique to that
1:53:49particular username. So, that when any
1:53:52user comes to this entry and if they
1:53:55write ABC, no other user can write ABC.
1:53:59If they want to use the same username
1:54:01again, they will not be added into our
1:54:03databases. Why? Because this username
1:54:06field is unique. The next constraint is
1:54:10not null. So, not null basically
1:54:11represent a value which can't be null.
1:54:14Null is the default value for any
1:54:16entity, right? So, whenever we want a
1:54:19field to have a particular value either
1:54:21given by a system or server or given by
1:54:25our user, we want to have that value.
1:54:27So, we can't have null in that. If we
1:54:30see in users table, the first name can
1:54:33easily come under the not null category.
1:54:35So, we don't want our first name to be
1:54:37null because we are going to address our
1:54:39user with their first name. So, this is
1:54:41a required field. The next constraint is
1:54:43primary key. So, our primary key acts as
1:54:46a unique identifier for that particular
1:54:48entity. In our whole user table, there
1:54:51is no record which can share that
1:54:53particular value. So, if we find any
1:54:56record with ID, let's say ID is equal to
1:54:58three, so only one record will come out
1:55:01of this. Okay? It can't give two records
1:55:04because the ID cannot be shared between
1:55:06two records. So, it will give a unique
1:55:09record out of our users table. So, our
1:55:11primary key basically helps us to track
1:55:13down to that particular record. And
1:55:15also, it helps us when we deal with
1:55:18multiple tables because there we might
1:55:21need some ID to put into some other
1:55:23table as a foreign key. So, in that
1:55:25concept also, primary key is used. With
1:55:28this, we can have a fourth option here,
1:55:31which is check. Check is basically used
1:55:33in order to maintain the authenticity of
1:55:36any record. Let's say we are using a
1:55:38password. So, while creating a password
1:55:41or while having a password, we might
1:55:43want our user to use certain constraints
1:55:46like the length should be greater than
1:55:48eight or maybe it should have any
1:55:51numeric values or it can have one or two
1:55:54special characters also. So, all these
1:55:56rules which we apply are applied in the
1:55:59DB for that particular column through
1:56:02the check constraint. Also, the other
1:56:04example of this can be a mobile number
1:56:07or a phone number. So, a phone number
1:56:10will only contain numeric values. It
1:56:12can't have any characters apart from
1:56:14that. So, this is also a check which we
1:56:17can apply for our phone number field.
1:56:20Also, the checks can be applied to any
1:56:22field. Let's say for first name, we
1:56:24can't have any name whose length is less
1:56:27than maybe two because A B C D, this
1:56:30can't be stored as a name. The shortest
1:56:32name I know is Om, right? It is also two
1:56:35characters long. So, we want to have
1:56:38that check. So, all the checks are
1:56:39covered with the check constraint. Now,
1:56:42with this,
1:56:43let's move to the other constraint,
1:56:45which is foreign key. So, let's
1:56:47understand foreign key through an
1:56:48example. Let's say we are creating a
1:56:50blog site where we have users table
1:56:52again. So, the users table is basically
1:56:55the authors table. Or let me rename it
1:56:58to author then.
1:56:59So this contains the list of all the
1:57:01authors who are going to publish some or
1:57:03the other blogs. So there we have this
1:57:06ID and then from this ID, let's say we
1:57:09only have two fields, first name
1:57:11and last name. We can have multiple
1:57:14fields if you want. For the sake of this
1:57:16example, I'm creating this smaller. So
1:57:19let's say we have one and the author is
1:57:21Akshat Agarwal.
1:57:23Let's say I have two authors. Okay. Now
1:57:26these two authors are not going to write
1:57:29only single post. They are going to
1:57:31write multiple posts. So we will have to
1:57:33create a separate table for posts and in
1:57:36that post we will have some ID. I'll
1:57:39have data or maybe content is the better
1:57:42word. So I'll change the name data to
1:57:44content. And that content is provided by
1:57:48some or the other author. So here we
1:57:50will have author ID also. So now let's
1:57:52say our post, first post, have some data
1:57:55about HTML and who wrote that post?
1:57:59Maybe Akshat. So for Akshat, I'm not
1:58:01going to write the entire details about
1:58:04the author again into this table. So for
1:58:06that, what I will use, I'll use the
1:58:08common identifier which is our ID. So
1:58:11our ID is our primary key here and which
1:58:14will be used as the foreign key here. So
1:58:16this is our foreign key and we will
1:58:18simply write one. With this particular
1:58:20information, we are going to get that
1:58:22okay, this author ID is one that means
1:58:25it is written by Akshat. Similarly, if
1:58:28we have multiple fields like this, let's
1:58:30say post two is on AI maybe and it is
1:58:34created by Gaurav.
1:58:36So we don't have to write the entire
1:58:38fields or entire information about
1:58:40Gaurav. Only the primary key will do.
1:58:44So from this two, we are going to again
1:58:46recognize that it is written by our
1:58:48second author who is Gaurav. So this is
1:58:50the role of our foreign key to establish
1:58:53the connections between two entities.
1:58:55With this, we also have a next
1:58:58constraint, which is default. So,
1:59:00default basically stands for the area or
1:59:02the field where we can't have null. So,
1:59:05null is not an option. And we don't want
1:59:08our user also to have that entry as a
1:59:10mandatory field. We can fill in for
1:59:13them. Let's say we are building anything
1:59:15for subscription. And if user have not
1:59:18paid anything to get a subscription,
1:59:20they might be having free as the value
1:59:23because they are currently using our
1:59:25free subscription. So, this is one case.
1:59:27The other case can be, let's say you are
1:59:30into our learn.telesco.com, right? So,
1:59:33this is our LMS and we are creating
1:59:34them. So, in this, every new user or the
1:59:38more number of users are going to be
1:59:40students only. And only few users are
1:59:43going to be managers or trainers or
1:59:45maybe admin. So, those are few
1:59:48categories and most of them are going to
1:59:51be students. So, the default value of
1:59:54role for every user here is student.
1:59:58Student/learner.
2:00:00So, either student or learner, we can
2:00:02have as a default role. And with time,
2:00:04let's say one or the other student or
2:00:06learner got hired into Telesco only to
2:00:08maintain the notes or maybe to teach,
2:00:11then we will update their role to
2:00:13trainer. This is how the system works
2:00:16with default. So, these are all the
2:00:18constraints which we have in our
2:00:19databases. Now comes the next part of
2:00:22our relational databases. One of the
2:00:24most important part is join. Join is
2:00:27basically used to associate two tables.
2:00:30That means to manage relationships
2:00:32between multiple tables. And why do we
2:00:34do that? To basically maintain
2:00:36relationships between different
2:00:37entities. So, let's see how many joins
2:00:40options do we have. The first and the
2:00:42most common join option is one to many.
2:00:46So, we have a users table. We have ID
2:00:49here, and we have F name only.
2:00:52Again, I'm going to use the same entry,
2:00:54one and two. And here, I can write any
2:00:56name. So, here are the two names, Akshay
2:00:59and Gaurav. Two entries basically for
2:01:01this users table. And again, we are
2:01:03creating a blog site. So, that means
2:01:05both Akshay can write multiple blogs,
2:01:08and Gaurav can also write multiple
2:01:10blogs. So, we will create another table
2:01:13to maintain our blogs, which will have
2:01:16ID, the content, and the author ID. So,
2:01:19maybe the first blog, which is on HTML
2:01:23again, is written by Akshay. The second
2:01:25blog is on AI, which is written by
2:01:28Gaurav. And then, there is third blog,
2:01:31which is on system design, which is
2:01:33created by Akshay. So, here we have one
2:01:36to many relationships.
2:01:38Because for a single record here, we
2:01:40have multiple options or multiple rows
2:01:43associated with that particular row. So,
2:01:45this is one to many relationship. With
2:01:47this, if we reverse this, we can also
2:01:49have many to one relationship. So, what
2:01:52we will do? Here, we were talking about
2:01:54users to blogs relationship. And here,
2:01:57we are talking about blogs relationship
2:01:59with users. So, here we can safely say
2:02:02that multiple blogs are associated with
2:02:05the same user. So, here we can have
2:02:07multiple blogs associated with the
2:02:10single user. So, this is many to one
2:02:12relationship. Now, let's move forward
2:02:15for our third relationship, which is
2:02:17many to many. So, in order to understand
2:02:19many to many, let's again go to our LMS.
2:02:22So, in LMS, we can have students.
2:02:25And we have courses here, right?
2:02:27Students also, we have ID maybe, and
2:02:30only F name is here right now.
2:02:33And in course, we have ID, and then we
2:02:36can have the course name here. Now,
2:02:38let's fill in some entries here. So,
2:02:41here we have students as Akshaya and
2:02:43Gaurav. And our courses are Master Java,
2:02:45Master AI. Now, Akshaya as a student can
2:02:49enroll into multiple courses. So, we can
2:02:51sense that from students, we can have
2:02:54multiple relationship for courses. And
2:02:58also, one course can have multiple
2:03:01students. And it is also possible that
2:03:03in Master Java, we have both Akshaya and
2:03:06Gaurav. So, that means our students
2:03:09can enroll into same course. So,
2:03:12whenever we see a situation like this
2:03:15where we can have many students or many
2:03:17records from single table associated
2:03:19with the single record of another table,
2:03:22and vice versa is also true, we are
2:03:24going to get a many-to-many
2:03:26relationship. So, in order to maintain
2:03:27multiple relationships, we have to have
2:03:30a
2:03:31junction table in between. So, this is
2:03:33our students-courses
2:03:35table. And here, we will have a unique
2:03:38ID of this particular record. Maybe this
2:03:41is required, maybe this is not, based on
2:03:44your queries and use cases. Here, we
2:03:47will have students ID. And here, we will
2:03:50have course ID. And now, while entering
2:03:52the data, we can simply say the record
2:03:54one, we have Akshaya enrolled in Master
2:03:57Java.
2:03:58Now, record number two, we have Akshaya
2:04:01again enrolled in Master AI. Then, for
2:04:04the third record, we have Gaurav
2:04:06enrolled in Master Java. And the fourth
2:04:08record, Gaurav enrolled in Master AI as
2:04:11well. So, with this junction table, we
2:04:13are going to figure out how many
2:04:15students are enrolled in how many
2:04:17courses, and how many courses have how
2:04:21many students. I hope this makes sense.
2:04:23This is a little confusing if you are
2:04:25starting, but this is how we maintain
2:04:27many-to-many relationships. With this,
2:04:29we can have one more relationship, which
2:04:31is one-to-one. Suppose we are building a
2:04:35platform like YouTube or blog site which
2:04:38also have podcast, which also have maybe
2:04:42video section. So, we have three kind of
2:04:45content, right? The first content is
2:04:47text for blogs. The second content is
2:04:51audio, and the third kind of content can
2:04:53be video.
2:04:54Now, the processing of all these
2:04:56contents are different. We can handle
2:04:58these multiple options by two ways.
2:05:01Either create a common table
2:05:04named as contents. So, in content now we
2:05:07have three types. For video, we are
2:05:09going to store MP4. For audio, we're
2:05:12going to store MP3 maybe. And for text,
2:05:15we're going to use the text which is
2:05:16there in database. We can use varchar,
2:05:19long text, short text, maybe text. Now,
2:05:21there are three kind of content. We can
2:05:23basically divide them by using a field
2:05:26which is type. So, in type we will have
2:05:29options like text, audio, or video. So,
2:05:32here the first record can be on again
2:05:35HTML, which is a blog type text type.
2:05:38So, we will type one here or text
2:05:40directly here. For the next content, it
2:05:42can be anything. Let's say the content
2:05:45is on improve focus, and in order to
2:05:47make that content, we don't have a
2:05:49video. So, we have something like audio
2:05:52here. And for the third thing, we have
2:05:54any video, let's say
2:05:56system design.
2:05:58And for this video, we have the type as
2:06:00video. Now, if you have worked into
2:06:03systems with these type of content, the
2:06:05processing of each type is very
2:06:07different. And if we curate all these
2:06:09data into a single table, it is going to
2:06:12be a really heavy one. Now, what are the
2:06:14drawbacks of having a heavy table? That
2:06:16is, whenever we are trying to filter, we
2:06:19have to basically filter through each
2:06:21and every content type and each and
2:06:23every record as well. So, instead of
2:06:26having all these kind of data into
2:06:28single table, what we can do is we can
2:06:30segregate the data already into multiple
2:06:33tables and have those IDs as a foreign
2:06:35key.
2:06:36So, the other approach is we will create
2:06:39a simple contents table where we will
2:06:42have ID here again and maybe the content
2:06:46name.
2:06:47And then we will not have the entire
2:06:49video or audio. What we will have, we
2:06:52will have the ID of that particular
2:06:54content. So, that means we are going to
2:06:55create multiple tables, one for videos
2:06:59and one for audios and one for maybe
2:07:02blogs. They all will have a common ID.
2:07:06With common ID, I mean their primary key
2:07:09and we will use the ID from videos, from
2:07:11audios and from blogs into this
2:07:14particular table. So, we will not have
2:07:16all the data here. Here we will only
2:07:19have content ID maybe. And with this, we
2:07:22can also have content type. So, this
2:07:24type will determine where we need to
2:07:26follow. So, this content table will only
2:07:29contain all the fields which user can
2:07:31search. They can search for name, they
2:07:33can search for type, they can search for
2:07:35maybe some keywords, some slugs. So, all
2:07:38these details will be there in our
2:07:40content field. And the actual data, the
2:07:43actual content will not be in the
2:07:44contents field but in their respective
2:07:47tables. So, all the blogs will contain
2:07:50all the blogs, all the audios will
2:07:52contain all the audio files, all the
2:07:54videos will contain all the video files.
2:07:56So, now if we have one and type as
2:08:00video, we know that one is going to
2:08:03fetch some data
2:08:05from this videos table where the ID is
2:08:08equal to one.
2:08:09So, this is one to one relationship.
2:08:13Where we know that we are using a
2:08:15different entity to our entity and the
2:08:19relation between us is one to one.
2:08:21Whenever we write one here,
2:08:23we are not going to fetch any other data
2:08:26and also we are not going to use the one
2:08:29again in this table. So, this is
2:08:31one-to-one relationship. So, we have
2:08:32understood that in relational DB, we
2:08:35have entities, right? And we join
2:08:38multiple entities through relations.
2:08:41That means every entity will have
2:08:42particular set of properties, and then
2:08:45they will be joined, and we will get the
2:08:47data accordingly. Let's understand the
2:08:49same thing with the example of posts and
2:08:51comments. So, suppose we are building a
2:08:54blog site, and in blog site, we have
2:08:56some post, and then we have some
2:08:58comments. The post table will have some
2:09:01ID, unique identifier, then some content
2:09:05associated with the post. Now, content
2:09:07can be anything, right? It can be
2:09:08images, it can again be text, or
2:09:13sometimes it can be video, also. So,
2:09:15these all are the category of post. Now,
2:09:18we have different type of posts, but we
2:09:21have to somehow pass those IDs and
2:09:23manage three tables for image, text, and
2:09:28videos. We can manage them in the same
2:09:30table, as well, but that will increase
2:09:32our latency, because different kind of
2:09:34formats are curated into a single table.
2:09:37That will increase the size, right? With
2:09:39content, we can also have content type,
2:09:42through which we will basically apply
2:09:43some filters, if we want to. Now, if we
2:09:45talk about it, we already have four
2:09:48tables. One for images, one for videos,
2:09:51one for text, and one for content. Now,
2:09:54we will have comments, as well. So, in
2:09:57order to have comments, we will have
2:09:58some comment ID, and then we will have
2:10:00comment. Now, comment can also be a sub
2:10:03comment of a parent comment. So, that
2:10:05means we can have a parent kind of
2:10:08comment ID, as well. Now, in order to
2:10:10handle comments, we have to handle
2:10:12users, also. Now, in order to handle
2:10:14user, we need one more table. We will
2:10:16have ID, maybe name here. So, our number
2:10:19again got increased to six. Now, in with
2:10:22this PID, we will also have user ID who
2:10:25is commenting on our post. So, in order
2:10:28to maintain a simple post and comment
2:10:31section, we will have to have
2:10:34four to five to six tables, right? And
2:10:37then we have to maintain the
2:10:38relationships as well. So, that means
2:10:40even for a small blog site, we will have
2:10:43to maintain so much data. And when the
2:10:45size of the blogs increase, with that I
2:10:48mean this will get hard to scale. Now,
2:10:51why I'm saying it is hard to scale?
2:10:53First, understand how can we scale any
2:10:55database? We have two options only,
2:10:57right? First is by scaling them
2:11:00vertically, and the second option is by
2:11:02scaling them horizontally. In vertical
2:11:05scaling, what do we do? We add the
2:11:07capacity to a single server. So, that
2:11:10means if we are using 4 GB data, we will
2:11:12add more space into our server to have
2:11:15more data. We can only expand this kind
2:11:19of vertical scaling to a extent. After
2:11:22that, we will have to use horizontal
2:11:25scaling. That means having different
2:11:26servers across different places. So, in
2:11:29this case, we will have to maintain
2:11:31relationships between the different
2:11:33entities
2:11:35in all of these databases.
2:11:37And this will be a tedious task. So, in
2:11:40order to avoid this, we can use NoSQL.
2:11:43So, we can say the first advantage of
2:11:45using NoSQL databases is it is easy to
2:11:48scale both vertically and horizontally.
2:11:52Because we will have to maintain a
2:11:54single document, and we can replicate it
2:11:57on different servers or even split them
2:11:59into different partitions and pass it to
2:12:02different servers. We will understand
2:12:03about that also in a bit. Now, what is
2:12:06the next issue? The next issue is
2:12:09if we are maintaining a table, we can't
2:12:13change the table again and again. We
2:12:15have some fixed columns, right? We have
2:12:18some fixed attributes or columns. We
2:12:21can't add or remove different column
2:12:23types in order to maintain different
2:12:25kind of data. Now, let's say we are
2:12:28going to handle the blog site, but this
2:12:30time we are going for NoSQL database. In
2:12:33this, what we can do now, we can create
2:12:35again and content entity and we can
2:12:39basically use any kind of content which
2:12:41we want. So, we'll create the first
2:12:43object and maybe we'll write something.
2:12:46Let's say user ID is one, then we will
2:12:48write the content. Here, the content is
2:12:51an image, so let me pass some URL. https
2:12:55maybe something something.jpg.
2:12:58Now, when we are adding next content,
2:13:00let's we can add it directly into the
2:13:02same content document. So, what we'll
2:13:05do, we'll again use some user ID. Maybe
2:13:08this time it is two and in form of
2:13:10content, now we have some textual data
2:13:13and we can have some text. Also, if you
2:13:15want to use it in a more refined way, if
2:13:18you want to add some rows, we can use
2:13:20that, right? We can use user ID as
2:13:23three, then maybe heading as anything,
2:13:27let's say Java, and then maybe we can
2:13:29have some description. This is
2:13:32description. And like this, we can have
2:13:35as many fields as we want. So, that
2:13:37means in a single entity content, we can
2:13:40have different fields and also we can
2:13:43have different number of fields in the
2:13:45same document. And if we go about
2:13:48relational database, we can't do that
2:13:50there, right? So, in these kind of
2:13:52scenarios where the document structure
2:13:53is not fixed, this is basically called
2:13:56schema-less, we need to go for NoSQL
2:13:59options because in SQL we don't have
2:14:01this option. So, that comes to our
2:14:03second advantage of using NoSQL, that is
2:14:06we can handle schema-less objects as
2:14:09well. So, now let's discuss about third
2:14:11point. So, in NoSQL up to now we have
2:14:14seen it is easy to scale, then it is
2:14:17schema-less and what makes NoSQL more
2:14:21feasible is when we don't have to handle
2:14:24a lot of linking between different
2:14:26entities. That is we don't have to
2:14:28maintain a lot of relationships between
2:14:30different entities and also every entity
2:14:33in a NoSQL database stands on its own.
2:14:36Think of this as a key-value pairs.
2:14:38Let's say a course ID. ID is the key
2:14:42here and in the course content we can
2:14:45have anything. We can have only name or
2:14:49we can have entire object. Or in third
2:14:51place we can have entire course with
2:14:55lesson. Of course there are going to be
2:14:57nested lessons in a course structure.
2:14:59Again with lessons in fourth place we
2:15:02can have course which will contain some
2:15:04lessons as a nested object and those
2:15:06lessons can also contain some comments.
2:15:09Now all these things are possible in
2:15:11NoSQL which were not there in SQL. If we
2:15:14want to have similar structure in SQL we
2:15:16have to maintain different entities and
2:15:18we have to maintain different
2:15:19relationships between them. Here we
2:15:21don't have that struggle. So that makes
2:15:23our NoSQL work easy. So this is why we
2:15:26use NoSQL over SQL and with time it is
2:15:29gaining popularity. For example in
2:15:31Netflix we use Apache Cassandra in order
2:15:34to maintain user activities. In Amazon
2:15:36they use DynamoDB in order to scale
2:15:38their application. In Facebook or Meta
2:15:41they use HBase in order to maintain user
2:15:44messaging and large-scale storage. In
2:15:46Uber they use MongoDB in order to handle
2:15:49flexible and real-time data. And with
2:15:51that Twitter or X use Redis for caching
2:15:55and timeline purposes. So the conclusion
2:15:58is that NoSQL is also being used in
2:16:00variety of systems nowadays. Let's
2:16:03distinguish it for a bit now. So when we
2:16:06should go for SQL and when we should go
2:16:09for NoSQL. Whenever we are handling
2:16:11payments, we don't have so much variety
2:16:14there. So, payments can be easily
2:16:16managed through SQL. So, with payments,
2:16:19we can also think about transactions or
2:16:22any other feature which needs
2:16:24consistency where the data is not
2:16:26changing, the schema is not changing,
2:16:27and also we need to handle those
2:16:30relationships perfectly. In all those
2:16:32areas where we need consistency, we can
2:16:35easily pick SQL. Now, when do we pick
2:16:38NoSQL? When we are talking about scaling
2:16:41and also we can talk about speed because
2:16:44as in NoSQL, we have a single document
2:16:47to search from whether in SQL, we have
2:16:49different entities or tables who are
2:16:51joined through one or more
2:16:52relationships. So, we have to traverse
2:16:54multiple tables in a SQL database and in
2:16:57NoSQL, we don't have to do that. So, by
2:16:59that nature, the speed of NoSQL database
2:17:02is faster than the speed of SQL one. And
2:17:05also, one of the core reasons to use
2:17:07NoSQL is
2:17:08unstructured data. So, in other words,
2:17:11whenever the consistency is on more
2:17:13priority than availability, we can
2:17:16easily pick SQL. And when availability
2:17:19and scalability is on more priority than
2:17:22strict consistency, we can choose NoSQL.
2:17:25With this, I hope you all get why we use
2:17:28NoSQL databases also with SQL and in
2:17:31what areas will we pick SQL over NoSQL
2:17:34and vice versa. Now that we have
2:17:36understood what NoSQL database is and
2:17:38why do we use that, let's see some
2:17:40examples and application areas of NoSQL
2:17:43database. Now, the thing is in SQL, we
2:17:46have only considered all the databases
2:17:49which will have tables, similar
2:17:51relationships, and in NoSQL, there can
2:17:54be various ways in which we can store
2:17:56data because it is like saying Java and
2:17:58NoJava. In Java, we have Java and in no
2:18:02Java, we can have many applications,
2:18:04right? So, like that, let's start by our
2:18:07first example, which is key-value pair.
2:18:10Now, if you are a developer or
2:18:12developing front-end, back-end, or
2:18:14anything, you must have used cache. We
2:18:17use the format of key and value whenever
2:18:19we are trying to insert some value in
2:18:20cache or maybe cookies or in data
2:18:23storage. We use this kind of data. So,
2:18:26if we talk about key, the only feature
2:18:29which a key should have is that a key
2:18:31should be unique. And for value, we can
2:18:34use any kind of value. We can use
2:18:36basically JSON or a string or maybe a
2:18:41number. Maybe if you want to add blob,
2:18:44we can use that. We can also store it as
2:18:48byte array or any array for that matter.
2:18:51We can also obviously have objects as
2:18:53well and we can also have the
2:18:55combinations of them. Like a list of
2:18:57object can be stored in an array or an
2:19:00object can also have nested objects. And
2:19:02with that, obviously, it will be having
2:19:04some strings, numbers, blob, byte array,
2:19:07or any of that values. Now, the two
2:19:10important points here are we don't have
2:19:12to follow any structure because the
2:19:15NoSQL database follows schema-less
2:19:17structure. So, we don't have to follow
2:19:21any structure. With that, we also don't
2:19:24have to maintain any relationships.
2:19:26Suppose, if you want to add post and
2:19:28comments, we can simply use any key.
2:19:31Let's say post is the key here, post one
2:19:33maybe. And in order to have that object,
2:19:36we can have any ID, post ID, or any
2:19:40content. So, these all things are key
2:19:42basically of this object. Post ID can be
2:19:45a number. Post content can be anything.
2:19:47And with that, we can have comments and
2:19:51we can have array of objects in
2:19:54comments. We can have multiple comments
2:19:56field also.
2:19:57Let's say it can have a comment ID and
2:20:00the actual content of the comment. Like
2:20:03this, it can have multiple objects and
2:20:05this all can be done without any
2:20:07relationships. So, this is a good
2:20:09example of key-value pair, which we
2:20:10normally use in our cache, cookies, or
2:20:13any other places where we don't need to
2:20:15maintain any structure. Now, let's move
2:20:17to the second one, columnar DB. So, the
2:20:19thing is whenever we are having any
2:20:21table, let's say we have student table,
2:20:23which have typical ID, a unique
2:20:25identifier, the name, and then the
2:20:28marks. Maybe total marks of all the
2:20:30students. So, ID is one, name is Akshat,
2:20:35and marks is maybe 90. With that, let's
2:20:37have one more record. The ID is two,
2:20:40name is Gaurav, and the marks maybe is
2:20:4495. Now, what we have to do is we have
2:20:46to get the average marks of class. So,
2:20:50the students is basically maintaining a
2:20:52class, we are assuming that, and all the
2:20:54marks, if we sum them, we will get the
2:20:56total marks, and if we divide them with
2:20:58the total number of students, we will
2:20:59get the aggregated marks. Now, in order
2:21:01to do that, if we do it in a SQL manner,
2:21:04the SQL manner basically reads the data
2:21:07from left to right. So, even if we don't
2:21:10require any name in our data, we have to
2:21:13still read our table from left to right
2:21:16for each and every row. This is a heavy
2:21:18task, right? Because we don't need those
2:21:20values. Here, we have only three
2:21:22columns. What if we have 17 columns?
2:21:25Then also we have to read all the rows
2:21:26from left to right, and which is not
2:21:28mandatory.
2:21:29So, in order to fix this issue, we have
2:21:31columnar DB. What columnar DB does is it
2:21:35gives us the flexibility to read the
2:21:37data column-wise. So, instead of reading
2:21:40it row-wise, now we can read the data
2:21:42column-wise. That means if you want to
2:21:45deal with only marks, we can read only
2:21:48marks data column-wise. And then we can
2:21:51aggregate all the marks. And if we want
2:21:53some other column, those can be also
2:21:55read by column-wise. And how we can link
2:21:59them? We can link them with the common
2:22:00IDs. So, the common IDs will be there
2:22:03whenever we are reading column-wise, and
2:22:05then it will be easier and faster
2:22:08through our unique identifier that is ID
2:22:10here. Where we are reading the data, but
2:22:13column-wise instead of row-wise. The
2:22:15common examples of columnar DB are
2:22:18Google BigQuery, Amazon Redshift, and
2:22:20Snowflake.
2:22:22So, all in all, if we have to read a lot
2:22:24of data, we can go for columnar DB. So,
2:22:26it is good for analysis. And imagine
2:22:30writing the data into columnar DB, that
2:22:32is going to take again a lot of time
2:22:34because we have to write also
2:22:35column-wise. So, that means we have to
2:22:37first maintain an ID, and then the name
2:22:40will be written, and then the marks will
2:22:42be written, and then the other values if
2:22:44we have them. Those will be also
2:22:46written. So, in order to read the value,
2:22:49it is useful. And when it comes to
2:22:51write, it is going to take more time
2:22:54than a SQL database. The third kind of
2:22:56NoSQL database is graph DB. Imagine, we
2:23:00have all seen those movies where
2:23:02detectives basically pinpoint many
2:23:04photos and join them with some thread or
2:23:07something, right? So, like this only, we
2:23:10have graph DB where we have different
2:23:13nodes, and they are joined by the
2:23:15threads which are called edge. So, every
2:23:18edge basically represent a common
2:23:20relationships between two nodes. Two
2:23:22nodes are basically the entities, and
2:23:25edge signifies the relationship between
2:23:28them. Now, what is different in graph DB
2:23:31is both nodes and edges can have
2:23:35properties. Suppose we are creating any
2:23:38node which is student, maybe, and which
2:23:41contain all the student information.
2:23:43Now, we have another node for course,
2:23:45maybe, and we can name the relationship
2:23:48anything. Maybe it is enrolled. Now, the
2:23:50enrolled can also have properties in it.
2:23:53It can contain year, it can contain
2:23:55marks. It can contain year of passing
2:23:58maybe. And all of these things the edge
2:24:01or the relationship can also have. So,
2:24:03this is what makes our system unique.
2:24:05Graph DBs are often used by data
2:24:07scientists to find patterns between
2:24:10different scenarios. It works basically
2:24:12in the same level which we see in any
2:24:14detective movie as well. So, if you want
2:24:16to work with graph DB, we can learn
2:24:19Gremlin or we can go for
2:24:22SparkQL. Also, we can use Cypher in
2:24:25order to work with graph DB. As I said,
2:24:28it is used in huge companies whenever we
2:24:30are dealing with a huge amount of data
2:24:32in order to face some patterns or
2:24:34basically analyze the customer behavior
2:24:37on our site. So, as we can see the two
2:24:39entities are going to have some
2:24:41properties and also the relationship
2:24:44between them will also have some
2:24:46properties. Also, two entities can have
2:24:49different relationships. And also it can
2:24:51be linked via different entities as
2:24:53well. So, student basically studies in
2:24:56this college. We can write all the
2:24:58parameters of the studies edge also. And
2:25:01college provides the course. So, in this
2:25:05provide relationship also we can have
2:25:07multiple properties. So, which makes our
2:25:10graph DB complex. And also since we are
2:25:13dealing with multiple entities with
2:25:15properties and also multiple
2:25:16relationship with different properties,
2:25:19it is going to be a bit slow. With this,
2:25:21let's move to our final and the most
2:25:23famous NoSQL database which is document
2:25:28DB. So, in document DB we will have some
2:25:31document and in that document we can
2:25:34write JSON and can store data with any
2:25:37length. We don't have to follow any
2:25:38structure, we don't have to follow any
2:25:40schema. So, that is flexible in nature.
2:25:43Also, it is schema-less. So, similarly,
2:25:46document DB also don't have to follow
2:25:48any relationship. At this point, if we
2:25:50think about this, the graph QL is kind
2:25:52of an exception on the borderline there
2:25:54because we do have relationships between
2:25:57them and with relationships, we also
2:25:59have properties of those relationships,
2:26:01which makes it entirely unique and
2:26:03different from no sequel and sequel
2:26:05both. But on a large level, it comes
2:26:07under the category of no sequel only.
2:26:09The common examples of document DB is
2:26:11CouchDB and also MongoDB is widely used.
2:26:15So, that is also an example of our
2:26:17document DB only. Our document DB is
2:26:20highly used in logging the systems
2:26:22because we need flexible log structures.
2:26:25So, it is highly used in logging,
2:26:27logging the error, maybe logging the
2:26:28warn messages, logging any kind of
2:26:30stuff. Also, it can be used to handle
2:26:33profile section because the profile
2:26:35section can also contain different
2:26:37values for different users. Suppose some
2:26:39have given all the values, some have
2:26:41given less values. So, that can be
2:26:42easily maintained through profile. And
2:26:45with that, if we talk about content like
2:26:47content on any application, let's say
2:26:50Instagram, we have different kind of
2:26:52content. We can have image, we can have
2:26:55video, or we can have some text. If we
2:26:58talk about Facebook here. Now, these
2:27:01different kind of posts or content don't
2:27:04have to go to different tables. In
2:27:06document DB, we can basically create a
2:27:08single document and curate all of these
2:27:11content into the same document,
2:27:13obviously with different attributes and
2:27:15values. So, again, as it is a no sequel
2:27:18DB, it is going to be complex and the
2:27:20retrieval of any information will be
2:27:22faster. Easily, any no sequel databases
2:27:25can be used for any kind of analysis.
2:27:28So, this is all about the types of no
2:27:29sequel databases. After understanding
2:27:31about databases, one thing is very sure
2:27:34that each and every important
2:27:35information needs to be stored in
2:27:37databases and will be retrieved from
2:27:39there itself. That means if we have any
2:27:42user here who is trying to access, let's
2:27:45say telesco.com only from their mobile
2:27:47application, the request eventually go
2:27:50to our backend and from backend if we
2:27:54are showing any information, it will be
2:27:56retrieved from the database and will be
2:27:58shown to our user. Now, the thing is for
2:28:01every information we need to hit our
2:28:03database. So,
2:28:05even if we have a homepage which have,
2:28:08let's say, three most popular courses
2:28:12aligned like this. This is our course
2:28:13one, course two, and course three. Maybe
2:28:17the details of each course are visible.
2:28:20One, a thumbnail is visible. Then, with
2:28:22that the name is visible. Maybe the
2:28:25price is also visible. And with price,
2:28:29the discounted price is also visible.
2:28:32Also, let's say we are showing some of
2:28:34the important sections. So, yeah. These
2:28:38are all the details of every course
2:28:40which is visible on our homepage. Now,
2:28:43this maybe is coming from any DNS
2:28:46because that's where we are saving any
2:28:48static files, remember? The name will be
2:28:51stored in a table. Let's say the table
2:28:53name is course or courses. For price, we
2:28:57may have the prices in the courses table
2:28:59itself, but according to area, according
2:29:02to the currency, the price keeps on
2:29:04changing. So, we will create a separate
2:29:07tables for prices. So, the price is
2:29:10coming from price. Then, the discount
2:29:12price also based on the locality. So,
2:29:15these both details are coming from the
2:29:16same place, prices table. And then, the
2:29:19important section. Important section may
2:29:21have some criteria or some course
2:29:23content which we need to show. So, this
2:29:26maybe it is coming from courses section
2:29:28only, but courses section normally have
2:29:30the course main course detail and then
2:29:33accordingly we can have different
2:29:35sections. So this is maybe courses table
2:29:37and we can create some other table which
2:29:40will have all the information for
2:29:42courses. We can name it as course info.
2:29:45So here also the things are coming from
2:29:48course info table.
2:29:50So that means in order to show these
2:29:52three courses we are hitting 1 2 3 and 4
2:29:57resources, three tables and one DNS. And
2:30:00that means that for every user who is
2:30:03trying to access our site telesco.com,
2:30:05it is going to hit all of these four
2:30:07resources again and again. So if the
2:30:10count increases to 10,000 maybe
2:30:14daily active users that means we are
2:30:17going to hit the database and the DNS
2:30:2010,000 times for each and every user.
2:30:23Also don't forget that the courses are
2:30:25three.
2:30:26Maybe in future we will increase the
2:30:28number to six. So that means 10,000
2:30:31requests multiplied by six
2:30:34that is 60,000 requests. In short, for
2:30:37every view we are hitting six courses
2:30:41and from those six courses we are
2:30:43hitting these four sections. So for
2:30:46every user we are hitting 24 requests.
2:30:49This is totally going to break our
2:30:51system because 24 requests means it will
2:30:54add latency to our home page. And in
2:30:57these fast times where nobody wants to
2:30:59wait for any resources, these latency
2:31:02are eventually going to affect our
2:31:04business.
2:31:06Also the more the latency the poor the
2:31:08performance. So this is clearly not a
2:31:11good sign. We can't keep hitting our
2:31:13databases again and again in order to
2:31:15fetch the same information for each
2:31:17user. We need some other mechanism. So
2:31:19this is where cache comes into the
2:31:22picture.
2:31:23Now let's understand what cache is.
2:31:26Cache is nothing but a memory storage,
2:31:30which is away from databases and it can
2:31:33either be in our backend or into our
2:31:35front end in order to load the resources
2:31:37faster. Now, how does it work? Let's
2:31:39take the same example. Our user is
2:31:41trying to access telesco.com and is
2:31:45hitting backend
2:31:46to get the information and backend
2:31:48eventually is hitting database to get
2:31:50the information. Now, once we understand
2:31:53that these six courses are going to be
2:31:55static on our home page, right? So, that
2:31:58means we don't want to fetch this
2:31:59information again and again from our
2:32:01databases. So, what will we do?
2:32:04We will eventually get that particular
2:32:07information and put it onto our backend
2:32:11either or we can also put the same
2:32:13information on our frontend storage as
2:32:16well. So, when the user again comes on
2:32:18telesco.com, we don't have to hit the
2:32:20entire database again and again. We have
2:32:23that information handy on our backend or
2:32:26frontend or in both the areas. So,
2:32:29whenever we hit our home page again, we
2:32:31can get those information directly
2:32:33through our cache, which is stored
2:32:36either on our frontend or on our
2:32:38backend. Here, we are saying that our
2:32:40user is accessing mobile device. Maybe
2:32:43it is accessing our site through any web
2:32:45application.
2:32:46So, there also we can handle cache,
2:32:48okay? These caches, which are on client
2:32:51side, are normally referred as client
2:32:53side cache. And the data, which we
2:32:56stored in backend systems, are referred
2:32:58as server side cache. In databases also,
2:33:02there is some mechanisms where they can
2:33:05also store the information ahead of
2:33:07time, that is known as well. And we can
2:33:10get the most requested information from
2:33:12this data only. We don't need to hit our
2:33:16database tables. Also, we can have cache
2:33:19in DB as well, which is known as
2:33:20database cache. Up to this point, we
2:33:23have understand why do we need cache
2:33:25from a very high level point. Now, let's
2:33:27understand how can we implement the
2:33:29caches in the real system. In order to
2:33:31understand them, first we have to make
2:33:33sure that we know some of the terms.
2:33:35The first term which we need to know is
2:33:37cache hit. Now, what is cache hit? Cache
2:33:40hit basically means let's say we have
2:33:43any request which is coming from our
2:33:46front end to back end. Let's say we have
2:33:48cache installed here and here is our
2:33:51final DB. Now, whenever we are hitting
2:33:54the request and we found the data in the
2:33:56cache, that is known as a cache hit
2:33:59scenario where the data is present in
2:34:01the cache and we don't need to hit our
2:34:03database. But, if the data which we are
2:34:06trying to get is not in cache and we
2:34:08have to hit our database, that is known
2:34:10as cache miss. So, what is cache miss
2:34:13here? Cache miss is again we are trying
2:34:15to access some data
2:34:17from our back end and we don't find the
2:34:20data in our cache. Instead, we have to
2:34:23get to our database to fetch that
2:34:25particular data. So, from where we are
2:34:27getting the data in cache miss? We are
2:34:29getting it from database. And from where
2:34:32we are getting the data in cache hit
2:34:34situation? We are getting it from the
2:34:36cache itself. So, whenever we hit a
2:34:38cache hit kind of situation, our
2:34:40responses will be faster. And similarly,
2:34:42in cache miss, our responses are going
2:34:45to be slower. With this, the next term
2:34:47which we need to know is TTL.
2:34:50TTL basically means time to live. Time
2:34:53to live basically specifies for how long
2:34:56the data is going to be in the cache. In
2:34:58other words, we can also say after how
2:35:01much time our data is going to expire
2:35:03from cache. Up to now, I hope we have
2:35:06understood what cache really is.
2:35:08So, how do we store data in cache? We
2:35:11store the data in cache in normally a
2:35:14key value form. And we get these data by
2:35:17using the keys, obviously, and by value,
2:35:20we also have TTL with them.
2:35:22In order to check whether the time is
2:35:25expired for that particular key-value
2:35:27pair or not. If it is expired, this
2:35:29key-value pair will be eliminated from
2:35:32our cache so that it makes room for
2:35:34having more data. So, at this point, we
2:35:36understand that the cache works faster
2:35:39than our databases. Then, why don't we
2:35:41get all the data from our databases and
2:35:44put it in cache so that every request
2:35:46which we make will be faster. If you
2:35:48understand software development, you
2:35:50understand that I'm asking a silly
2:35:52question. But, if you are new, just hear
2:35:54me out. Now, this is those kind of
2:35:56question where the answer lies in the
2:35:58question itself. We are saying that
2:36:01cache is faster. Now, let's understand
2:36:03why it is faster. Because we are only
2:36:06collecting the information which is
2:36:09frequently used. Okay, so that's why the
2:36:12size of our cache is very smaller than
2:36:16our DB. Because DB have all the
2:36:19information which our site needs. So,
2:36:21that means the size of cache is limited.
2:36:24And we have to keep refreshing the data
2:36:26in cache so that it performs well.
2:36:30Why do we need to refresh? Let's say
2:36:32today we have some campaign of maybe
2:36:34selling our most sellable course, maybe
2:36:37Java we are selling on the let's go. We
2:36:39are saying mastering Java. So, you can
2:36:42master Java. This is our most prominent
2:36:44course today. But, tomorrow we change
2:36:46our focus from Java to maybe AI. Let's
2:36:49say most students are not interested to
2:36:52learn Java at that time. But, are
2:36:54interested to learn AI. At that time, we
2:36:57have to replace the content of Java to
2:37:00AI.
2:37:01So that we can get this information
2:37:03faster. Why it is faster? Because it is
2:37:06easy to find something in a limited
2:37:09space than in the entire database. That
2:37:12is why cache is faster. And the second
2:37:14point is if let's say somehow we managed
2:37:17to create a large size of cache itself
2:37:20and we managed to save our entire
2:37:22database into cache, in that case, every
2:37:25search query or everything which we are
2:37:26trying to find is going to take a longer
2:37:28time into our cache itself. So, it
2:37:31defeats the whole purpose of having a
2:37:33cache. That is to reduce the latency and
2:37:36to get the performance better. So, with
2:37:38this two points are very clear. First is
2:37:41the size of our cache needs to be way
2:37:44smaller than the size of our DB so that
2:37:47we can get the responses very faster.
2:37:50And now that we have size constraint, we
2:37:52need to keep updating the cache data in
2:37:55order to get the values which are
2:37:57relevant to our users. Now, I think we
2:37:59are very sure what cache is, why the
2:38:02size is limited, why do we need to
2:38:04refresh the content again and again.
2:38:06Now, it's time to go a bit deeper. Let's
2:38:09go into the strategies through which we
2:38:11can update the cache data. The first
2:38:14strategy is read through cache. As the
2:38:18name suggests, read through cache
2:38:20strategy is designed to handle the reads
2:38:23from the cache only, not the rights. So,
2:38:26let me create a diagram. Let's say this
2:38:27is our server. Here we have our back end
2:38:30and our cache and with this we have our
2:38:33actual database here. So, read through
2:38:35the query suggests that every time we
2:38:38have a request of getting any
2:38:40information, we are only going to read
2:38:44through cache. We are not going to hit
2:38:46database. We are only going to read the
2:38:49information from cache. And if and only
2:38:53if the data is not present in our cache,
2:38:55then only we will need to hit our
2:38:57database.
2:38:59Again, for right, we are not going to
2:39:01write any value in our cache. We are
2:39:03directly going to write our data into
2:39:06our database. So, in order to read, we
2:39:08are going to hit our cache, and in order
2:39:11to write, we are going to hit our
2:39:12databases. Here, clearly, we can have
2:39:15two cases. The first case is
2:39:18cache hit. In case of cache hit, that
2:39:20means we are trying to get some
2:39:22information, the back end is going to
2:39:24hit our cache, and cache have that
2:39:26value, right? Cache returns that value
2:39:29to our back end system. So, this is
2:39:31good. This means that we are going to
2:39:33have a faster retrieval. Then, we have
2:39:36our case two for cache miss. What
2:39:39happens here is our back end is again
2:39:42going to ask our cache whether they have
2:39:44the information or not. And in this
2:39:46case, as this is cache miss, that means
2:39:49we don't have that information into our
2:39:50cache. So, here, cache itself is going
2:39:53to ask to our database
2:39:56and fetch that particular data. So,
2:39:58database is going to give that
2:40:00information to our cache, and then cache
2:40:02will return the data again to BE. So,
2:40:05clearly, it adds a next level step to
2:40:08get the data from database, which is
2:40:10going to make this request call slower.
2:40:13So, that means whenever we are reading
2:40:15any data, we are not going to go to
2:40:18database directly. Our cache will be
2:40:20connecting to database and getting the
2:40:22value which is required for our back
2:40:24end. And from cache, we are going to
2:40:27give that value again to back end in
2:40:29order to process it. So, here, if you
2:40:31see what we are doing, we are not adding
2:40:33any recently added data directly to our
2:40:35cache. We are adding data directly to
2:40:38our databases, and only the data which
2:40:40is getting retrieved from our users are
2:40:43going to be in our cache. Let's say,
2:40:45from our back end, we are making an
2:40:47order placement, and that data we are
2:40:50not seeing that again. So, that means
2:40:52that data is never going to come to our
2:40:54cache because no one is accessing that.
2:40:57Only the data which user is accessing
2:40:59are going to come to our cache, which
2:41:02makes our cache always ready with the
2:41:04information which user wants. So, this
2:41:06is all about RTC. Let's move to the
2:41:08second strategy, which is WTC. WTC
2:41:12stands for write through cache. As in
2:41:16RTC, the strategy is only for reading,
2:41:18here this strategy is only for writing.
2:41:21So, that means we have again our client
2:41:24application. Here we have our backend
2:41:26and our cache with our database. Now,
2:41:29whenever we are going to write any data,
2:41:31we're going to write it into cache and
2:41:34then eventually from cache, the data is
2:41:36going to be there into our databases.
2:41:39So, this means whenever we are writing
2:41:41any data, we're going to write it into
2:41:43our cache first and from cache, the data
2:41:46is going to be written into databases
2:41:47finally. So, by doing this, our cache
2:41:50data is always going to be updated with
2:41:53the latest value. Where it can be used?
2:41:55It can be used if we talk about stock
2:41:57values, where we always want to see the
2:42:00latest data. And with this, it can be
2:42:02used to any other application where we
2:42:03want to see the latest data first. With
2:42:06this, let's move to the third strategy,
2:42:08which is WAC. WAC basically stands for
2:42:12write around cache. So, up to now, we
2:42:15have only talked about either read or
2:42:17write. With WAC, we're going to talk
2:42:20about read and write both into one
2:42:22strategy. So, read around cache. So,
2:42:26when it comes to write, we are going to
2:42:28write the data from any query from our
2:42:30client, it is going to call our backend
2:42:32services and from backend, we are
2:42:34directly going to write the data into
2:42:37our databases. No cache is in between.
2:42:40So, that means all the writes will be
2:42:42directly dumped into our database. And
2:42:45we haven't updated any cache here. So,
2:42:48this is about write. And with read, what
2:42:50we are doing, whenever we are reading
2:42:52any data, we are going to read it always
2:42:55from cache. If the data is there in our
2:42:58cache, that is a cache hit situation,
2:43:02then we're going to get this information
2:43:04directly. So, this is good. If we get
2:43:06any cache miss kind of situation, where
2:43:09the data is not there in our cache, the
2:43:11cache is going to call database and
2:43:13update the value in the cache first and
2:43:16then will give the value to our backend.
2:43:19So, this is how WAC works. You may think
2:43:22that it is a combination of RTC and WDC,
2:43:25which is correct. So, in RTC and WDC, we
2:43:28are only talking about read and write
2:43:31respectively. But, in WAC, we are
2:43:33talking about the entire flow of data.
2:43:36So, it is heavily used in applications
2:43:39like Twitter. Now, it is called X. So,
2:43:42here the scenario is we have a lot of
2:43:45users who are going to create tweets.
2:43:49But, we can't directly create those
2:43:51tweets and save them in our cache,
2:43:52right? And whenever the users are trying
2:43:56to access any tweet, at this point it is
2:43:58decided to keep this tweet in cache
2:44:01memory because now it can be used by
2:44:04some other users as well. So, we don't
2:44:07decide the importance of any tweet at
2:44:10the time of its creation. We decide the
2:44:13importance at the time of reading those
2:44:14tweets, right? So, with WAC, we also
2:44:17have one more strategy, which is WBC.
2:44:21WBC basically stands for write back
2:44:25cache, which basically means whenever we
2:44:27are trying to write any data, it is
2:44:30going to be written into our cache and
2:44:32at this point our write operation is
2:44:34completed. We are going to write this
2:44:36data into our database, but this is an
2:44:39async process. So, that means while
2:44:42writing our data, we don't care about
2:44:45consistency much, but we care about
2:44:47speed. We want to get the update faster.
2:44:51So, whenever we write any data into our
2:44:52cache, it is going to give us the okay
2:44:56response, maybe.
2:44:57And after that, the data will be dropped
2:45:00into our databases eventually. Now, as
2:45:03this is async process, it is very
2:45:06possible that we may get some or other
2:45:09error here.
2:45:11So, we have to handle this kind of
2:45:12scenario or strategy very carefully. And
2:45:15now, let's talk about read. While
2:45:17reading the data, again, we are going to
2:45:19read the entire data from our cache
2:45:21itself, right? That is the whole point
2:45:23of having a cache. So, as most of our
2:45:26data is directly written into cache, it
2:45:29is most likely to have the most updated
2:45:31values. So, normally, it is going to
2:45:33give cache hit. And if we get cache miss
2:45:37kind of situation, so we are again going
2:45:39to call our database, update our cache,
2:45:42and from cache, we are again going to
2:45:45read the value from our application. So,
2:45:47as you can see the WAC and WBC are
2:45:50pretty common, but here we are using
2:45:53async to write the data. That means we
2:45:56are trading off between speed and
2:46:00consistency. So, even if our data is not
2:46:03consistent, we are making sure that the
2:46:05speed of application remains fast. Now,
2:46:08WBCs are basically used where we have a
2:46:11high write traffic. The most common
2:46:14example of this can be any food delivery
2:46:17application. Let's say Swiggy or Zomato.
2:46:20So, in Zomato or Swiggy kind of
2:46:22application, what normally happens is at
2:46:25a particular time, we may be handling
2:46:27multiple orders with multiple status.
2:46:30And the status keeps on changing. So,
2:46:32instead of saving all the data changes
2:46:35into our database, we choose to save
2:46:38them into cache. Because we know that
2:46:41the status of this particular order will
2:46:43change very fast. So, we use WAL here
2:46:47because we need to update the
2:46:49information fast and also the user who
2:46:52have created the order are also going to
2:46:55see the latest information through this
2:46:56cache only. And in the back process or
2:46:59in the backend or async manner, we are
2:47:02going to keep updating our databases.
2:47:04So, this way it is going to handle
2:47:06million of request and status updates at
2:47:09a particular time. So, up to now we have
2:47:11understood that how do we handle the
2:47:13data into our cache? But, we have only
2:47:16added the data. We haven't deleted the
2:47:18data. So, now let's understand the cache
2:47:21eviction policies through which we are
2:47:23going to remove the data which is not
2:47:25used by our cache. Here I'm writing
2:47:28policies here. We can easily use
2:47:30strategies. I just wanted to sound
2:47:32little different. So, that's why I added
2:47:33policies.
2:47:35Um just for fun, you may say. So, the
2:47:37first policy basically is LRU. LRU
2:47:42basically stands for least recent used.
2:47:47So, as the name suggest, least recent
2:47:50used.
2:47:51That means the data which is not used
2:47:54recently will be evicted from our cache.
2:47:57Suppose Apple launches a new iPhone
2:48:00which is 17 Pro
2:48:03Max updated something something very
2:48:07acronym synonyms of Pro Max Ultra
2:48:09something. And now everyone is keep
2:48:12looking for 17 Pro. No one is in today's
2:48:15time looking for 11. So, that means 11
2:48:19is a stale data which was used earlier
2:48:22by our cache maybe. But, in today's time
2:48:25we don't need to store that information
2:48:27into our cache because a very few clicks
2:48:30were there who were still searching for
2:48:3211. Now, with this let's talk about the
2:48:35second policy which is MRU, the exact
2:48:39opposite of LRU.
2:48:40There we were saying least here we will
2:48:43say most recent used. So here we are
2:48:46going to delete the data which is most
2:48:48recently used. This sound a bit strange,
2:48:51right? Why do we delete something which
2:48:52is most recently used?
2:48:54But if you think about it, let's say you
2:48:57are surfing through an e-commerce
2:48:58application and you already apply a
2:49:00particular coupon. So in that case we
2:49:03don't need that particular coupon into
2:49:05our cache, right? So we will directly
2:49:07remove that. Also, if you think about
2:49:10it, we have streaming applications. For
2:49:12example, let's say this YouTube only. So
2:49:14in YouTube's the streaming normally
2:49:17happens in sections. When you are
2:49:19watching any video, let's say you have
2:49:21watched the video till here. At this
2:49:23point this data gets loaded.
2:49:26And you may see a white line moving
2:49:29forward which denotes that the data up
2:49:32to that point is loaded right now. Let's
2:49:35say currently we are at this point and
2:49:37this data is already loaded. Now at this
2:49:39point we don't need the previous video
2:49:41information. This can easily be deleted
2:49:44from our cache at least.
2:49:47Because in this case the chances of me
2:49:50going back into the video is very slow.
2:49:52So that's where we remove the most
2:49:54recently used data. So I hope you are
2:49:57getting all the points. The next part,
2:49:59the next eviction policy is LFU. LFU
2:50:03basically stands for least frequently
2:50:07used. So LFU basically means the data
2:50:09which is not frequently used will be
2:50:12evicted from our cache. What does that
2:50:14mean? Let's say today I opened any e-com
2:50:18application and search for plant. Also,
2:50:21I am a gadget guy. I basically purchase
2:50:24a lot of gadgets. So suppose I have a
2:50:27history of seeing any secondary screen
2:50:31also. With that I also purchase a lot of
2:50:33clothes. So clothes section is also
2:50:36there. Now, between these three, I keep
2:50:39on seeing about the secondary screen and
2:50:41I keep on seeing the clothes in one or
2:50:44the other manner, but the plant search I
2:50:47only did once. Maybe I saw some YouTube
2:50:50video or liked some plant into some
2:50:53Instagram story of others. Only at that
2:50:55time I thought of purchasing a plant and
2:50:58after that I didn't think about it
2:51:00again.
2:51:01So, that means the plant is the least
2:51:04frequently used terms for my history of
2:51:07that e-commerce applications. So, now
2:51:09whenever we are going to evict any data,
2:51:11it is going to be this. So, this is
2:51:13another strategy where we remove the
2:51:16least frequently used data from our
2:51:19cache. After LFU, we have two standard
2:51:22ways of handling cache data or removing
2:51:25the cache data. The first strategy is
2:51:27FIFO. We all know about it. FIFO
2:51:30basically stands for
2:51:32first in, first out. Suppose we have
2:51:34assigned 180 MB to our cache and we
2:51:37don't want to exceed this limit.
2:51:40Now, whenever we are trying to add any
2:51:42value and and if we have reached our
2:51:44limit, first data which we are going to
2:51:47remove is the first data which we
2:51:49entered into the cache without thinking
2:51:51about anything, without thinking about
2:51:52frequency, without thinking about how
2:51:55recently they are being used. We will
2:51:57simply remove the first added data from
2:52:00our cache. And with this we have the
2:52:02last eviction policy which is LIFO. LIFO
2:52:05basically stands for last in, first out.
2:52:08You may think of a stack kind of
2:52:10situation here, right? Where the last
2:52:12object which is inserted will be evicted
2:52:15first.
2:52:16So, this is how LIFO works. So, in this
2:52:19what we will do, again we have 180 MB
2:52:21memory and here we I have written bytes.
2:52:24Here it is bits. Don't worry about that.
2:52:26It doesn't matter. Now, in that 180 MB
2:52:30memory, I don't want to store any other
2:52:32information. So, what information will I
2:52:35remove? I'll remove the most recent
2:52:37information which I added. Okay? So,
2:52:40maybe this information which is added
2:52:42first
2:52:44will be there for the longest time, and
2:52:47we will keep on removing this or this or
2:52:49this information in order to have more
2:52:52space for the added information. So,
2:52:54this is about LIFO and FIFO. I have not
2:52:57added any application areas for LIFO and
2:52:59FIFO both. I want you to explore this a
2:53:02bit and tell me in the comments. And
2:53:05with this, we have understood about
2:53:06caches, their eviction policies, and how
2:53:09do we add the data into our cache. I
2:53:12hope you all get it. Up to now, we have
2:53:14understood how our request basically
2:53:16flows through different components of
2:53:18our system and ultimately provide some
2:53:20information to our user. Right? We have
2:53:23seen who our customer is. They're going
2:53:26to interact with either some web
2:53:28application or maybe some mobile
2:53:30application.
2:53:31From where the request will flow to a
2:53:34server where our back-end code is, and
2:53:36through the server, we will hit some or
2:53:39the other database in order to retrieve
2:53:41that information and provide it back to
2:53:43the user. With this, we have also
2:53:45discussed about DNS through which our
2:53:48clients are going to get the address of
2:53:50our server. And then, the cycle repeats.
2:53:53So, this is all we know up to now. This
2:53:55all looks very good, works very
2:53:57efficiently up to a single point. Why?
2:54:00Because here we are using only single
2:54:03server, and a single server can scale
2:54:05only up to certain limits.
2:54:07Suppose we are already using 128 GB of
2:54:12our server, and somehow our processes
2:54:15are consuming this much resources. That
2:54:17means we are getting more requests than
2:54:19we were expecting. Maybe our app is
2:54:22tracking attraction now from across the
2:54:24globe. And at that time, we have no
2:54:26choice but to scale our system. In order
2:54:29to scale the system, this is the first
2:54:31step which you can think of.
2:54:33So, instead of having a single server,
2:54:35we need to have multiple servers. Let's
2:54:39name them server one and server two.
2:54:42So, we have two servers. That means our
2:54:44client need to give the call to either
2:54:47server one or server two. But, how our
2:54:50client is going to decide where to give
2:54:52information to? This is where we need to
2:54:54discuss one more component which is load
2:54:56balancer. Now, let's make the diagram
2:54:58again with load balancer. Now, what
2:55:00happens? Our client or the user is going
2:55:04to access the same information from any
2:55:06mobile application or website, and they
2:55:09are going to hit DNS in order to get the
2:55:13IP address of server. Up to now, things
2:55:16are not changing. Everything is pretty
2:55:17straightforward. But, now our DNS is not
2:55:21going to give the IP address of the
2:55:22actual server, but it is going to give
2:55:24the IP address of load balancer. And
2:55:27then, the load balancer is connected to
2:55:30multiple servers. Suppose this is server
2:55:32one,
2:55:33this is server two, this is server
2:55:35three. And then, the load balancer
2:55:37basically decides to which server our
2:55:40request should go to, whether it should
2:55:41go to S1, S2, or S3. And if it goes to
2:55:46S1, S2, and S3, they are basically going
2:55:48to connect to a database. Maybe they are
2:55:50connected to same database, or there can
2:55:53be a possibility that S3 is managing the
2:55:56data in some other database, and through
2:55:58migration, replication, or partitioning,
2:56:00we are handling the data between those
2:56:02databases as well. So, this is what the
2:56:05actual picture of a microservice
2:56:07applications looks like. Where the load
2:56:10balancer is going to play a huge role in
2:56:13order to pass those requests from client
2:56:16to server. Now, if we talk about load
2:56:18balancer in brief, our load balancer
2:56:21mainly is going to perform two tasks.
2:56:23The first task is how do it give
2:56:26responses to the perfect server from
2:56:28which it can get the response faster,
2:56:31right? So, the first thing is choosing
2:56:34the server. Also, if we are giving the
2:56:36responsibility of choosing the server to
2:56:38load balancer, that means load balancer
2:56:40should know how our servers are
2:56:42performing in the current situation. So
2:56:44that no server will be overheated and no
2:56:47server will be underutilized. So, the
2:56:50second thing
2:56:51which load balancers are going to do is
2:56:54maintaining the health checks of our
2:56:57server. So that whenever any new request
2:56:59comes to load balancer, they are the one
2:57:02who is going to decide whichever server
2:57:04is working in a fine condition plus can
2:57:07handle that request pretty well.
2:57:09So now, let's discuss these both points
2:57:11one by one. So, in order to choose a
2:57:14server, we need some algorithms, right?
2:57:16So, there are various algorithms and
2:57:18hybrids also from which our load server
2:57:21decides where the request should go. So,
2:57:25let's discuss those algorithms. The
2:57:27first algorithm here is round robin.
2:57:30Round robin is the most simplistic
2:57:32approach in order to pick the web server
2:57:34for the next request. So, in round
2:57:36robin, what do we do? Suppose this is
2:57:38our load balancer and we have our server
2:57:41one here, server two here, and server
2:57:43three here. Load balancer is now going
2:57:46to pick server one for the first
2:57:49request. For second request, it is going
2:57:51to pick server two. For third request,
2:57:53it is going to pick server three. And
2:57:55where will the fourth request go? It
2:57:57will again go to server one. Then five
2:58:00for server two and six for server three.
2:58:02And this is how every request will keep
2:58:05generating and going to the next server
2:58:07which is in the list. So, there is no
2:58:09much calculation needed here. We only
2:58:11need to know that we are following the
2:58:13sequence of S1, S2, and S3. And if the
2:58:16current request is being processed by
2:58:18S2, the next request is going to be on
2:58:21S3. This is how round robin works. So,
2:58:24that means round robin send request one
2:58:27by one, right? Apart from this, it
2:58:30doesn't check anything, which makes the
2:58:32round robin very easy to implement. That
2:58:35means if you are using round robin
2:58:37algorithm, each server are going to
2:58:40handle almost equal number of requests.
2:58:42So, we can say the distribution of
2:58:45requests are equal. And as in this
2:58:48algorithm, we are not managing any state
2:58:50of any server, basically, we'll manage
2:58:53only a single counter from which we are
2:58:56going to decide where the next request
2:58:58is going to be. And also, we need to
2:59:00manage where the current request is. So,
2:59:04with simple implementation, we can
2:59:05easily set up round robin into a load
2:59:08balancer. But, there are some demerits
2:59:10to it. What if server one, server two,
2:59:13server three doesn't have equal
2:59:15configurations? What if the RAM
2:59:17configuration between them is different?
2:59:20What if the storage is different? What
2:59:23if the CPU power is different? Let's say
2:59:26for S1, RAM is 4GB.
2:59:29For S2, it is 8GB.
2:59:32For S3, it is 16GB.
2:59:35Again, the storage, let's say for server
2:59:38one, we are using maybe 100GB storage.
2:59:42For server two, we are using 200GB
2:59:44storage. And for server three, we are
2:59:46using 500GB of storage. Also, the CPU,
2:59:50let's say it is 16 core, it is 32, it is
2:59:5364 core. So, the configurations are
2:59:56entirely different. And what we are
2:59:57doing in round robin, we are not
2:59:59checking any of these matrixes, but we
3:00:02are simply following the next counter.
3:00:04So, that means even if with uneven
3:00:07configurations,
3:00:08the load on server one, server two, and
3:00:11server three are going to be same. And
3:00:13this is unfair because the server three
3:00:16may do all the task very frequently and
3:00:18can sit idle. Whereas server one will
3:00:21struggle to complete the task and it
3:00:24will be overloaded, maybe heat up, maybe
3:00:26stop working. So, this is the demerits
3:00:29of using round robin. Now, let's jump to
3:00:31the second algorithm, which is
3:00:33geo-based, which basically states that
3:00:37suppose this is our load balancer and we
3:00:39have our server one again and server two
3:00:42again. This is in India and this is in
3:00:46US. So, if the majority of users are
3:00:50from India and some users are from US,
3:00:53that means they need to hit their
3:00:55respective servers in order to process
3:00:57the information. That way,
3:01:00they will get the response faster
3:01:03because if I'm sitting in India and I'm
3:01:05requesting any information from the
3:01:06Indian server, it will be faster to
3:01:09process those information in the Indian
3:01:10server as well with respect to
3:01:12processing the same information through
3:01:14US servers because the connections are
3:01:16going to take time and which will
3:01:18increase the latency of the application,
3:01:20which the user doesn't want, right? So,
3:01:22this is what our second algorithm
3:01:24implies. It is based on geo addresses of
3:01:28the particular user. So, here also we
3:01:30are not maintaining any matrices for
3:01:32server specifications. We are only
3:01:34maintaining two matrices. The number one
3:01:37matrix is where the server is and the
3:01:40second matrix is from where are we
3:01:42getting the request or we can say where
3:01:45the user is. Now, this algorithm is used
3:01:48by many applications across the world
3:01:50whichever have the global appearance.
3:01:53Whenever we are trying to hit google.com
3:01:55or facebook.com or any other global
3:01:57applications, our request basically
3:02:00moves to the server whichever is closest
3:02:03to us. Maybe we are residing in this
3:02:05area. Here we have some server and also
3:02:08here we have some server. Maybe this is
3:02:10US server, this is Indian server.
3:02:13So, our server needs to be situated near
3:02:16us so that we get the response faster
3:02:19and all the requests are maintained
3:02:21through the same server. So, whenever
3:02:23I'm trying to access any information,
3:02:25they are going to be addressed through
3:02:27the same server. So, that means our
3:02:29session and other informations are also
3:02:32will be in sync for this particular
3:02:34user. In this algorithm, there are some
3:02:37disadvantages as well, right? Because
3:02:39now our load server needs to manage more
3:02:42information.
3:02:43Now, it needs to know from where the
3:02:46requests are coming and it needs to know
3:02:48where each and every server is located.
3:02:51So, this is a lot of information to be
3:02:54seen by load balancer. And now as our
3:02:56servers are distributed across the
3:02:58globe, we also need to maintain
3:03:01databases accordingly. So, every region
3:03:04may have their own databases for faster
3:03:06retrieval. So, that will include the
3:03:08computation power of replication and
3:03:10partitioning, which we will be covering
3:03:12in further series. Also, let's say
3:03:16if we are using Indian server or this
3:03:18server particularly, maybe there are two
3:03:20servers in India. This is India B
3:03:22server, this is India A server. For some
3:03:25reason, this server breaks down.
3:03:28Then we need to reroute our request to
3:03:30this particular server, which is again
3:03:33needs all the information which we are
3:03:34accessing through this server. That
3:03:36means the data or the application on
3:03:38which we are working on should transfer
3:03:40the data immediately to this server as
3:03:43well. Even if the server A doesn't
3:03:45crash, then we need all the information
3:03:47which is being tracked by server A. But
3:03:50this is a necessity in geo-based
3:03:52location algorithm. Now, the third point
3:03:54here is if any user is using VPN or
3:03:58other proxy servers to change their
3:04:00location, that means VPN or proxies can
3:04:03mislead the traffic. With this, let's
3:04:05move to our next algorithm, which is
3:04:07least connection algorithm. So, in this,
3:04:10what happens is we have our load
3:04:12balancer in place.
3:04:14And suppose we have two servers, server
3:04:16one and server two. And server one and
3:04:19server two at current times are managing
3:04:22multiple requests, right? Suppose S1 is
3:04:26maintaining
3:04:2730 requests or 30 connections at this
3:04:29particular time and S2 is maintaining 50
3:04:32connections.
3:04:33Now, whenever we get a new request, it
3:04:36is going to be addressed by S1. Why?
3:04:39Because S1 currently is having least
3:04:41connections.
3:04:43So, this is how our least connection
3:04:45algorithm works. Whichever server have
3:04:48the least connections, our next request
3:04:50is going to that particular server. In
3:04:52this algorithm also, we are not
3:04:54considering any of the matrices of
3:04:57server. We are also not maintaining any
3:04:59of the requests or response time. We are
3:05:02only maintaining the number of
3:05:04connections. Let's say if these 30
3:05:07requests are heavy request and these 50
3:05:10are lightweight, then also the next
3:05:13request is going to be taken care by S1,
3:05:16which is wrong and it is going to take
3:05:18time, but this is how our least
3:05:20connections work. Then why do we use
3:05:22this? Basically, the least connection
3:05:24algos works very well when there are
3:05:26sticky sessions. Now, what is sticky
3:05:29session? Where we have to maintain a
3:05:32proper channel for a particular
3:05:33communication. Let's say we are using
3:05:35web sockets for maintaining any kind of
3:05:38application. Let's say we are
3:05:39maintaining a chat application or a
3:05:41video streaming application or maybe we
3:05:44are handling some gaming kind of setup.
3:05:47In all of these cases, we needs the
3:05:49request and response to be faster, so we
3:05:52will pass our request to those servers
3:05:55who are having least connections
3:05:57currently so that we can get the
3:06:00response faster. Now, if we talk to
3:06:03disadvantages, the first disadvantage is
3:06:05this only heavy and lightweight. Maybe
3:06:07these calls are for AI calls which are
3:06:09going to take time and these calls are
3:06:12basically chat calls or maybe some web
3:06:14CTR calls or maybe some REST API calls
3:06:17which are lightweighted normally. So,
3:06:19they are working faster then also we
3:06:22will send the next request to 30 until
3:06:24the number of connections drops from 50
3:06:26to maybe 29. Then only we will consider
3:06:29S2. So, this is how we are going to
3:06:31work. Now, if we talk about
3:06:33disadvantages of least connections, the
3:06:35first we already discussed. The second
3:06:38disadvantage is that our load balancer
3:06:40basically needs to maintain the number
3:06:42of connections for each web server. So,
3:06:45if S1 is maintaining 50 connections at
3:06:48that time and it give response to one of
3:06:50them, that means currently it is
3:06:52maintaining 49 connections. It needs to
3:06:55be updated to load balancer. So, our
3:06:58node balancer will keep updating the
3:07:01number of connections again and again
3:07:03which is of course a tedious task. The
3:07:05third disadvantage is we are only
3:07:07considering least number of connections.
3:07:10What if our server one is of very low
3:07:13configuration than server two
3:07:15and it is maintaining eight connections
3:07:17at that time or request at that time and
3:07:20this is maintaining 16.
3:07:22It is easy for S2 to maintain 16
3:07:24connections or maybe 100 connections and
3:07:26it is hard to maintain 10 connections
3:07:28for S1. Then also we will send the next
3:07:31request to S1 because we are not
3:07:33checking anything apart from number of
3:07:35connections. So, this is how our least
3:07:37connection algorithm is going to work.
3:07:40After least connections come least time.
3:07:43So, it is our fourth algorithm least
3:07:46time algo. Suppose load balancer is
3:07:50maintaining two web servers S1
3:07:53and S2. The response time of S1 is
3:07:57nearly about 50 ms. The average response
3:08:01time, basically. It is handling some
3:08:03thousand requests, and for server two,
3:08:05it is currently 10 ms. So, in this
3:08:08scenario, the next request is going to
3:08:10be handled by server two. Because the
3:08:13average response time of server two is
3:08:15lesser than the average response time of
3:08:18server one. Now, if we talk about
3:08:20response time, if any server is having
3:08:22less response time, that means the
3:08:24configurations of those servers are
3:08:27high. Right? That's why the response
3:08:29time is low. So, this algorithm
3:08:32basically takes care of the actual
3:08:33matrices of the server by taking the
3:08:35response time into measure. Now, the
3:08:37least time algorithm is used in those
3:08:39applications where we can't handle more
3:08:42latency. That can be our real-time
3:08:44applications, like the trading app or
3:08:47even our search engines. In both of
3:08:50these areas, we want the responses to be
3:08:52very fast, and that's why we use least
3:08:54time algorithms there. And now, if we
3:08:56talk about least time algo's
3:08:58disadvantage, that is our load balancer
3:09:02needs to calculate the average response
3:09:04time. So, with each request they are
3:09:06sending to server, also the average
3:09:09response time will be calculated. And
3:09:11based on this, our load balancer needs
3:09:14to manage where the next request is
3:09:16going to be. So, calculating these
3:09:18things can be really complex because if
3:09:20we are calculating average time, that
3:09:22means we need to know number of maybe
3:09:24requests, and also the response time of
3:09:28each and every response. Then only our
3:09:32load balancer is going to calculate the
3:09:33average response time. So, this is for
3:09:36sure complex. Now, in this scenario, if
3:09:39our web servers maintain any kind of
3:09:41spike, it is going to affect the
3:09:43calculations of our load balancer. So,
3:09:45we need to be very careful there. Now,
3:09:47let's talk about the fifth algorithm,
3:09:49which is IP hash. Here, as the name
3:09:52suggests, the IP of every request is
3:09:56going to be processed by our load
3:09:58balancer and will be given a unique
3:10:00number.
3:10:02And according to those numbers, our
3:10:04servers are going to decide. Let's say
3:10:06our server one is maintaining the hash
3:10:08values from one to 10. So, that means
3:10:10all the IPs which results between this
3:10:13range are going to be addressed by S1
3:10:15and maybe from 11 to 20 are addressed by
3:10:18S2.
3:10:19So, this is how IP hash algorithm works.
3:10:23Every request is associated with some of
3:10:25the other IP. They are going to process
3:10:27through a hash function, and suppose the
3:10:29result is five, then it is going to be
3:10:32addressed by S1 because S1 is
3:10:34maintaining one to 10. As we all know,
3:10:36the IP of any user normally doesn't
3:10:39change. That means this user for at
3:10:41least one session is going to be
3:10:43addressed through the same server. And
3:10:45it will help. Basically, if we are
3:10:47maintaining any session data, it is
3:10:49going to help because we don't need to
3:10:50replicate this data to other servers. We
3:10:52are only handling these requests through
3:10:55the same server. So, it is very easy.
3:10:57Now, if the connection breaks in between
3:11:00the session, then we are in problem. In
3:11:03that case, this next request will go to
3:11:06S2, and we need all the session data
3:11:08here. And if that data is not
3:11:10maintained, our user may need to address
3:11:13or add the same data again into server
3:11:15two, which is a loss case, which is not
3:11:17recommended at all. So, for this to work
3:11:19efficiently, our server basically needs
3:11:21to be healthy enough to maintain a
3:11:23proper session. Plus, even if the
3:11:26session breaks due to any reason, due to
3:11:28any server crash, it is very important
3:11:31to replicate those data to other server
3:11:33as well. The major disadvantage of this
3:11:36is, as we are basically focused on IP
3:11:39functions and hash functions, so scaling
3:11:42is challenging here. Let's say we are
3:11:43adding S3 here, then we again needs to
3:11:47reconfigure our hash function. So, that
3:11:50it consider S3 as well. And also, we
3:11:52need to reassign these values also.
3:11:55Maybe next time it is only handling 1 to
3:11:588, and maybe it is handling
3:12:00uh
3:12:019 to 12 maybe, and this one is handling
3:12:0412 to 20. So, whenever any server is
3:12:07down or we are adding any new server,
3:12:10basically the function will get affected
3:12:12and it will reassign all the values to
3:12:14the entire server. This is hard to scale
3:12:16in this manner. And that's why it is not
3:12:19recommended for most of the
3:12:21microservices architecture we have
3:12:23today. It is basically used where the
3:12:25data was used in the old kind of
3:12:27applications where the applications were
3:12:30monolithic and mostly were legacy apps.
3:12:34Like in today's scenario, if you want to
3:12:35maintain a session of a particular user,
3:12:37we don't only stick for that particular
3:12:39session. We use many other tools like
3:12:42JWT token we use, right? So, this is how
3:12:45we are going to maintain an entire
3:12:47connection through a server and a
3:12:48client. We don't only rely on giving the
3:12:51request to the same server again and
3:12:53again. Even if the server changes, it is
3:12:55going to recognize us through our JWT
3:12:57token. And this is going to work
3:12:59excellently with our distributed
3:13:01systems,
3:13:02microservices, and also if we use Redis.
3:13:06In all these scenarios, we now don't
3:13:08need IP hash functions. We don't need
3:13:11our request to be handled through same
3:13:13server. Even if the server changes, our
3:13:16request or our session should be
3:13:18consistent. Also, there is another
3:13:20algorithm which is extension of round
3:13:22robin, which is called weighted round
3:13:24robin. So, in which the round robin, as
3:13:27it was discussed, is working same, but
3:13:30we added weight. So, that means
3:13:33let's say this is S1, this is S2, and
3:13:36this is S3. Let's say the RAM capacity
3:13:39of S1 is 8 GB, for S2 it is 16, and for
3:13:43S3 it is 32 GB. Now, what we are doing,
3:13:47we are adding a weight to our request.
3:13:50So, more the configuration,
3:13:52more is going to be the weight. So, if
3:13:55our load balancer basically keeps track
3:13:58of this, so it knows that the S3 may
3:14:01have weight three, S2 may have weight
3:14:03two, and S1 may have weight one. So,
3:14:06whenever a new request arrives at load
3:14:09balancer, it is going to be addressed by
3:14:12the one which have the most weight. So,
3:14:15here the weight of S3 is maximum, so it
3:14:17is going to be addressed by our S3
3:14:19server. And then, based on the weight
3:14:21and round robin fashion, our request are
3:14:24going to be answered. So, with weighted
3:14:26round robin algorithm also added in the
3:14:28list, we have now covered all the
3:14:29algorithms, major algorithms basically,
3:14:32which we needs to know when we talk
3:14:34about load balancers. Also, in real
3:14:37base, no one algorithm basically works.
3:14:39We always work with hybrid approach.
3:14:42And load balancer basically balances
3:14:45multiple algorithms. It is very possible
3:14:48that we are using maybe IP hash with the
3:14:51combination of round robin. And also,
3:14:54other combinations are also possible.
3:14:55Maybe we are combining two, maybe we are
3:14:58combining all six at the same time. Like
3:15:00here, we were talking about least time
3:15:03algorithm and least connection
3:15:05algorithm. We can combine these two
3:15:07algorithms in order to get a better
3:15:08algorithm. So, in order to fulfill our
3:15:11requirement, we normally don't rely on a
3:15:13single algorithm, we rely on multiple
3:15:16hybrid algorithms. So, after discussing
3:15:19all the algorithms, we know now how the
3:15:21load balancer basically chooses a server
3:15:23for the next request. The second thing
3:15:25which load balancer does is doing the
3:15:28health checks. Let's understand how load
3:15:30balancer basically manages the health
3:15:32checks. Here the thing is we have two
3:15:34approaches how a load balancer can check
3:15:37the health checks of entire servers.
3:15:39Let's say we have a load balancer here
3:15:41again and we have server one
3:15:45and server two. The first way how we can
3:15:47check any performance is by simply
3:15:49seeing how server one and server two are
3:15:52performing. We are not adding any new
3:15:54request in server one or server two. We
3:15:56are just observing how they are
3:15:58responding to the actual requests. This
3:16:01is the passive way of checking the
3:16:02health. By this, we don't add any new
3:16:05request to the servers. We don't
3:16:07basically increase the load of any
3:16:09server, but we simply observe. By we, I
3:16:13mean load balancer. The load balancer
3:16:15simply observe how the server one is
3:16:18responding to request and maintain that
3:16:21track. And let's say at a particular
3:16:23point, if server one breaks or stops
3:16:25responding, at that time the load
3:16:27balancer knows about this by again
3:16:30tracking the actual request. It doesn't
3:16:33add any new request to server one. So,
3:16:35this is what the passive way is. Now,
3:16:38there is another way which is active
3:16:40way. In active way, what a load balancer
3:16:42does is it adds additional request to
3:16:45our servers. And based on the responses
3:16:48on those requests, it checks the actual
3:16:51health of the server. So, these are the
3:16:53two ways of checking the health of
3:16:56servers. One by simply observing the
3:16:59request and second by actively adding
3:17:01the request to the servers. It is very
3:17:03important to check the health of every
3:17:06server. Why? Because it gives us the
3:17:08pattern to take decisions. Like when to
3:17:11scale or when to scale down. Both of
3:17:14these cases are very usual by working on
3:17:16any application on a day-to-day basis.
3:17:18Let's suppose if we are maintaining our
3:17:20application only for India region, in
3:17:23that case also we know that in day time
3:17:25the requests are going to be heavy.
3:17:28Maybe in evening time it will be
3:17:29heavier. And in night time it is going
3:17:31to be little or lesser in count. So, at
3:17:35that time we can maybe scale down our
3:17:37server in the night time in order to
3:17:39save some cost. So, let's see what are
3:17:41the other parameters of health checks.
3:17:44The first parameter of health check is
3:17:47interval. This means how often do we
3:17:49check our server? For example, it can be
3:17:52maybe 5 seconds. So, if the case is
3:17:54active, every 5 seconds I'll monitor all
3:17:57the requests I've sent to the server and
3:18:00see how the performance is going. And
3:18:02also, in the passive case we'll see the
3:18:05responses and calculate the matrices
3:18:07every 5 seconds. The second params can
3:18:10be time out. So, time out basically
3:18:12means for how long do we wait to get the
3:18:15response? Suppose there is any server
3:18:18who normally takes from maybe 50
3:18:20milliseconds
3:18:21to the maximum of maybe 5 seconds
3:18:25in order to process any request from a
3:18:28long time. And now suddenly it is taking
3:18:3110 seconds. So, this should be an
3:18:33alarming case and we should immediately
3:18:35check what went wrong. Okay, with that
3:18:37particular web server. What is that
3:18:39particular request which is taking 10
3:18:41seconds? Is there any issue with the
3:18:43code? Is there any issue with the
3:18:44request? Does Do we change any
3:18:47configuration? Or does our server is
3:18:49managing some other task because of
3:18:51which our this request is being
3:18:53affected? We need to know the answers of
3:18:56all of these questions in order to make
3:18:57a better decision. We also need to know
3:18:59about the threshold. Threshold can be
3:19:02like healthy and unhealthy both, right?
3:19:04In unhealthy, we basically take care of
3:19:06the failed calls. So, we will basically
3:19:09maybe set an alarm after 20 failed
3:19:13calls. Okay? We can configure them based
3:19:16on a particular region, based on a
3:19:18particular area of our code, maybe a
3:19:21route, particular subdomain of a route,
3:19:24or maybe randomly. At a particular time,
3:19:26if 20 calls fail, that is an alarming
3:19:29situation for us. In normal scenario,
3:19:32many application may give a faulty
3:19:34response based on various factors. It
3:19:36happens on a day-to-day basis, but after
3:19:38that n threshold, after that count of
3:19:41threshold, we should start investigating
3:19:44the cause. And similarly, we have our
3:19:47healthy threshold, where we should put
3:19:49our marker maybe after every some calls.
3:19:53So, maybe after every 100 calls, 100
3:19:56positive calls, we need to check is
3:19:58everything fine with those calls. The
3:20:00response was expected, and the system is
3:20:02working the way it should work. So,
3:20:04these are the three health parameters of
3:20:07our web servers which our load balancer
3:20:09needs to check end over time in order to
3:20:11make sure that our web servers are
3:20:13working fine. And with this, we now
3:20:15understand the two major factors of load
3:20:17balancer, how it gives request to the
3:20:20other server, and plus, how do it check
3:20:23the health of every server. Now that we
3:20:25have understood load balancer, it is
3:20:27very important to know that in terms of
3:20:29scaling, we also need to scale our
3:20:31databases, right? So, in databases, what
3:20:34normally happens is, suppose we have 100
3:20:36GB of data, and we have a storage of
3:20:38maybe 200 GB. This is still fine, right?
3:20:41Maybe we have 1 TB of data, maybe 100 TB
3:20:44of data, it doesn't matter. The thing
3:20:46which matter is this data will
3:20:48eventually get full.
3:20:50And there will come a stage where you
3:20:53can't expand your databases vertically.
3:20:56You have to add more databases into our
3:20:59system
3:21:00whenever it comes to scaling. Also, now
3:21:03that we know about load balancers, we
3:21:05know that our server
3:21:06can be placed into different regions of
3:21:09our world, right? This can be placed
3:21:10into US region, this can be placed into
3:21:13India region only. And what we were
3:21:15doing is we were adding both of these
3:21:17data into single database. This is
3:21:19effective if the user count is one, the
3:21:21request we are getting are minimal. But
3:21:24if the user increases, the traffic
3:21:26increases, the data increases, it will
3:21:28be hard to cater both of these servers
3:21:30from the single database.
3:21:32This is where we need to segregate this
3:21:34data into multiple databases. One may be
3:21:38catering Indian server and the other
3:21:40might be catering the US server. Now,
3:21:42this way we segregated our data into two
3:21:44databases so that the requests can be
3:21:46faster and also with that the data will
3:21:49be segregated in such a manner that it
3:21:51will be easy to maintain. Now, this can
3:21:53be one of the case where we don't need
3:21:56to have same data into two databases. In
3:21:59this case, what we are doing, we are
3:22:00assuming that the data in this data
3:22:02table will be different from the data
3:22:05into this database. Normally, this is
3:22:07not the case, right? Normally, what can
3:22:09happen is suppose we have multiple
3:22:12servers for Indian region only. So, this
3:22:14is also Indian region, this is also
3:22:16Indian region. And we can have multiple
3:22:18databases to cater the same server. Why?
3:22:21Because if we have a single database and
3:22:23if that fails, we don't have anywhere to
3:22:25go and recover the data from. That's why
3:22:27we manage multiple databases in order to
3:22:30recover the data, maybe maintain the
3:22:32data, and also it increase the
3:22:34efficiency of our system by reducing the
3:22:36latency. And also we may have some
3:22:38portion of data here and some portion of
3:22:40data here.
3:22:41Both of these things are possible. These
3:22:44things are basically
3:22:46replication and partitioning. In
3:22:49replication, what we do, we basically
3:22:51copy the data from one database to other
3:22:54database so that even if anything
3:22:56happens to database one, we are able to
3:22:59retrieve the data from database two.
3:23:00Also, if database one is handling so
3:23:03much calls, we can redirect those
3:23:05requests to database two as well. And in
3:23:07partitioning, what we do is we basically
3:23:09divide the data into single database and
3:23:12put one part here into other database
3:23:15and the other part anywhere else. So
3:23:17that if they are getting different
3:23:19requests, it will be easier to cater
3:23:21each and every request with their
3:23:22specific database. We are going to cover
3:23:24both of these topics, but for now let's
3:23:26talk about replication. So we have
3:23:28understood that replication basically
3:23:30means keeping the copy of data. And why
3:23:33are we doing this? Why are we making
3:23:35copies? The first point is we are
3:23:37avoiding or improving our single point
3:23:40of failure issue. We don't want our
3:23:41database to fail and our system to
3:23:43collapse. We want some other database at
3:23:45that time so that our system will be
3:23:47working. The other reason of this is
3:23:50availability. By having data into
3:23:52multiple databases, our availability as
3:23:54a system can increase. We can have
3:23:56different data centers and it will
3:23:58increase our performance. Also, as we
3:24:01discussed, if we talk about different
3:24:02localities or different regions of area,
3:24:05we are increasing the performance by
3:24:07adding particular database into that
3:24:09site. So that will keep the data close
3:24:11to our server and will be retrieved
3:24:13faster. And also with all this, we are
3:24:15eventually increasing our read
3:24:17throughput. So suppose with a single
3:24:20database, we were catering maybe 10,000
3:24:23requests per second. Now with two
3:24:25databases of same storage and data, we
3:24:27can cater two times of the previous one.
3:24:29So this is how the three throughput will
3:24:31also increase. So after understanding
3:24:33what replication is and why do we use
3:24:36it, let's talk about how can we achieve
3:24:38replication. So we are going to talk
3:24:40about three algorithms. The first
3:24:42algorithm is single leader replication.
3:24:46That means there will be a database
3:24:49which will be our leader and from the
3:24:52leader only we will replicate the data
3:24:54to other follower nodes or follower data
3:24:56centers.
3:24:57Suppose there is any user who is maybe
3:25:00updating their profile picture. And when
3:25:03they are updating their profile picture,
3:25:04the request from our client basically
3:25:07moves to a server and from server we are
3:25:10only sending that request to our leader
3:25:12only. We don't directly communicate to
3:25:15our followers because it is the leader
3:25:18who is going to then replicate our data
3:25:19to followers. So every request will go
3:25:22to our leader. To be specific, every
3:25:24write request will go to our leader and
3:25:26then the data will be replicated to our
3:25:28followers. This is how a single leader
3:25:31approach works. Let's understand this
3:25:33through an another diagram. This is our
3:25:35user. Maybe this is our leader and we
3:25:39have our F1 follower database and
3:25:42follower two. Assume this as a timeline,
3:25:45okay? Now what we are going to do,
3:25:46suppose at this point the user is
3:25:49requesting to update the profile
3:25:51picture. And this request will
3:25:53eventually go to our leader node and
3:25:56once the request is taken care by
3:25:58leader,
3:25:59they will send the same request to our
3:26:01follower nodes as well.
3:26:03Follower node one, maybe it is taking
3:26:05longer time because it is far. So at
3:26:07this point the request went to follower
3:26:10one and follower two. At this point two
3:26:12things can happen.
3:26:14First thing is if the calls from leader
3:26:16node to follower node are async, in that
3:26:20case leader will do its work and update
3:26:22the user that the task is done. And in
3:26:25the back processes, the follower nodes
3:26:27can continue updating the profile
3:26:29picture and will eventually update our
3:26:32leader that the task is done. This type
3:26:34of request where leader updates the user
3:26:37directly after updating the data without
3:26:39getting the acknowledgement from these
3:26:40follower nodes is called async
3:26:43operation. Async basically means once
3:26:46the request is catered by a leader, it
3:26:48will directly update our user. And in
3:26:51the back end, it will also share the
3:26:53same request for follower one and
3:26:55follower two node to perform the same
3:26:57task and update our leader in the back
3:26:59end. In this case, even if our F1 fails
3:27:02to update, F2 fails to update, or
3:27:04anything went wrong with these other
3:27:05nodes, the leader have already given the
3:27:07confirmation to our user. So, the task
3:27:10is done. And eventually, when the nodes
3:27:12are recovered, these operations will be
3:27:15performed again on F1 and F2 to keep the
3:27:18sync alive. After async, let's also talk
3:27:20about sync approach, where the user
3:27:22updates the profile picture.
3:27:24The request basically carried by our
3:27:26leader,
3:27:27and it sends the update request to our
3:27:30follower nodes as well,
3:27:31F1 and F2. And the leader in this case
3:27:35will not give any confirmation until it
3:27:37get the okay response from both of our
3:27:41followers. So, this gives okay,
3:27:44and again, this gives okay. Once it get
3:27:47confirmation from both of these follower
3:27:49nodes, then only our database is going
3:27:52to update our server, and eventually,
3:27:54our user that the task is done. So, this
3:27:56kind of approach is called sync
3:27:58approach, where the leader will provide
3:28:00the same operations to be performed by
3:28:02F1 and F2. It will wait for the
3:28:05responses, and once the response is
3:28:08taken, then only it will update the
3:28:10user. So, this is going to take a lot of
3:28:12time, because our databases can be
3:28:14placed into multiple places. There can
3:28:17be two follower nodes, as we have
3:28:18mentioned here, or more. So, in that
3:28:20case, our time will increase, and
3:28:22eventually, it will update the user
3:28:25after getting the confirmation from each
3:28:27and every follower. Now, let's talk
3:28:29about advantages and disadvantages of
3:28:31both of these approaches. If we talk
3:28:33about synchronized approach, sync
3:28:35approach, the advantage is all of the
3:28:38followers will always have the updated
3:28:39values. The other advantage of sync can
3:28:42be, even if our leader fails, it will be
3:28:45easier to select another leader, because
3:28:47every node we know have the current
3:28:50updated data. So, it will be easy to
3:28:52migrate our leader to any of the
3:28:54follower nodes, maybe follower one,
3:28:56maybe follower two. The disadvantages
3:28:59will be it is going to take a longer
3:29:01time and also after getting any request,
3:29:04our leader is waiting for the responses
3:29:07from other follower nodes. It is going
3:29:09to block that particular resource and
3:29:11other operations on that particular
3:29:13resource is also be blocked because of
3:29:15our asset principles, right? And because
3:29:18of these two disadvantages, we can say
3:29:21that the sync operation here while
3:29:23replication is an imprac- tical
3:29:25approach. Any leader can't wait for all
3:29:27the followers to update them first and
3:29:30then they will update the user.
3:29:32So, we always prefer async approach
3:29:34here. In async approach, as we can see
3:29:36clearly, no resources are blocked,
3:29:39right? And the responses will also be
3:29:41faster. And if we talk about
3:29:43disadvantages,
3:29:44we are basically trading off our
3:29:47consistency. That means our data will be
3:29:50mismatched. Suppose if a user is
3:29:53updating any data to leader node and
3:29:55leader provides the response to user,
3:29:57our user will assume that the task is
3:29:59done. So, even if they read from any
3:30:02other follower nodes, the data should be
3:30:04reflected. And in the async approach, it
3:30:07is very possible that if user is trying
3:30:09to access the data and it get connected
3:30:11to any follower nodes, it will see the
3:30:14stale data, which is eventually going to
3:30:16update by our leader, but currently they
3:30:18are seeing the stale data. So, this is
3:30:20the issue in our async approach. Now,
3:30:23before moving to the other algorithms,
3:30:25let's first talk about how can we add a
3:30:27new follower?
3:30:28So, let's say we already have a system
3:30:31where we have a leader and we have maybe
3:30:33follower one and follower two already in
3:30:36our system. Now, we need to add our
3:30:38follower three. How can we add it? Now,
3:30:41in order to add a new node into our
3:30:43system, we need to perform some
3:30:45operations. Our follower three will also
3:30:48need to have all the data which our
3:30:50leader have.
3:30:52So, for that, what we do, we create
3:30:54snapshot of the data from leader or
3:30:57maybe we can create it from follower as
3:30:59well. But, we need to make sure that if
3:31:02we are picking follower two in order to
3:31:04do the replication, we will again need
3:31:06to use F2 only to update the data. Let's
3:31:09say the current time is 12:55 p.m. and
3:31:13we are taking the snapshot of F1 or F2
3:31:16at this point. So, that means whatever
3:31:19the state of our F2 is at this 12:55
3:31:23p.m., we are only capturing the current
3:31:25state of that particular database and we
3:31:29are that dumping it into new node, which
3:31:31is F3. Now, this process is going to
3:31:35take time for sure. So, this is our
3:31:37snapshot one, which is at 2:55. So, this
3:31:41will contain the entire state of our F2
3:31:45node. Now, what will happen again is
3:31:47suppose the replication process took 2
3:31:50hours or 3 hours, maybe, because the
3:31:53data is huge and everything.
3:31:55Now, we need to know what changes did
3:31:57the F2 went through in this 2 and 3
3:32:00hours. So, in that case, what we will
3:32:02do, we will again take the snapshot, but
3:32:04this time we don't have to capture the
3:32:06entire state. We only need to capture
3:32:08the difference between the snapshot and
3:32:11the current time. So, we will create
3:32:13another snapshot, which will include the
3:32:15changes from 12:55 to current time. And
3:32:19finally, we are going to dump this data
3:32:21also in F3. Once we get to know that the
3:32:24F3 is completely in sync with F2 and F2
3:32:27is already in sync with leader, we will
3:32:30make the connections of leader to our F3
3:32:33also. And with this, we will have a new
3:32:35follower node into our system with all
3:32:38the updated data. After this, what
3:32:40happens if the leader only fails? Let's
3:32:42say we are having this topology again,
3:32:45leader, F1, and F2.
3:32:48Again, we have some databases linking.
3:32:51The replication process is working fine,
3:32:53then suddenly our leader fails.
3:32:56In this case, we need to elect a new
3:32:58leader. Now, how will we elect?
3:33:00Basically, we will take care of two
3:33:02factors. The first factor is which of
3:33:06these F1 and F2 have the latest
3:33:08information. So, we can take care of
3:33:10that by seeing the timestamp of the
3:33:12latest update. So, whichever we will
3:33:14see, we will pick from F1 and F2, and we
3:33:18will see which one is
3:33:20updated recently. And the second step is
3:33:23we need to update F1 to become a leader,
3:33:26and our F2 to see F1 as a leader now.
3:33:30So, this is the process of electing a
3:33:32new leader when the leader goes down.
3:33:34With this, you may have also heard these
3:33:36terms like FS image or maybe added logs.
3:33:40These things are highly used in the
3:33:42replication process. FS image basically
3:33:44con- tains the full metadata snapshot,
3:33:47and added logs is used to update the
3:33:49current changes. So, these both are also
3:33:52used while doing the replication. And
3:33:55while choosing the new leader or adding
3:33:57a new follower, these two things are
3:33:59also helpful. Now that we understand how
3:34:02to add new leader, how to add new
3:34:03follower, how to take care of things,
3:34:06let's move to our second algorithm,
3:34:08which is multi-leader algorithm. So, as
3:34:10the name suggests, it is having multiple
3:34:12leaders instead of one. So, that means
3:34:14there is a possibility that every data
3:34:16center, be it DS1 and DS2, will have
3:34:20their bunch of leaders and followers.
3:34:23So, maybe for DS1, we have this leader,
3:34:26and we have follower like F1 here. Also,
3:34:29here we have another leader and
3:34:32follower. So, for DS2, the leader is
3:34:35L2, and for DS1, the leader is L. Now,
3:34:38what is going to happen? Let's say the
3:34:40user is maintaining their records
3:34:43through DS1. So, every record which DS1
3:34:46handles will eventually first go to
3:34:48their leader, and then the leader will
3:34:50update their nodes. With this, now
3:34:53leader also needs to update the other
3:34:55leader into other data centers. And then
3:34:58this leader is going to update these
3:35:00nodes. This is how the process flows.
3:35:02And similarly, if any request is being
3:35:04made to this data center two, our leader
3:35:07two is going to update their followers,
3:35:10and also will send some query to other
3:35:12leader to update the leader as well as
3:35:15their followers. So, this is how a
3:35:17multi-leader replication works, where
3:35:19the leader will not communicate to each
3:35:22and every nodes, but it will communicate
3:35:24to leader nodes, and maybe their
3:35:26follower nodes. So, this is going to
3:35:29increase our performance. Also, we have
3:35:32multiple leaders, that means even if a
3:35:34leader node breaks, we can use the other
3:35:37leaders to update the other nodes. So,
3:35:39we have more tolerance to threats. Now,
3:35:42since we have two leaders, we can also
3:35:43perform collaborative operations, like
3:35:46they can be working on the same file.
3:35:49Now, we can work on the same Google
3:35:51file, same Google sheet, those kind of
3:35:53operation also we can perform, because
3:35:55one request will not block that
3:35:57resource, and the two requests can
3:35:59eventually work simultaneously. Now,
3:36:00when we are saying that both of these
3:36:03resources are going to perform actions
3:36:04on a similar table or single data, that
3:36:07is going to increase our chances of
3:36:09conflicts. Let me explain it through
3:36:11another diagram. Let's say this is user
3:36:13one, this is leader one. Here we have
3:36:16leader two, and then we have another
3:36:18user. Let me create the timelines again.
3:36:20Let's say, user one and user two both
3:36:22working on the same file, which is named
3:36:25as A. Now, user one wants to rename that
3:36:28file to B, and user two want to rename
3:36:32that file to maybe C. Now, these both
3:36:35will eventually hit their request to
3:36:38their particular leaders. And based on
3:36:40the async approaches we have seen, our
3:36:42leaders can eventually give the okay
3:36:45response to our users, right? That okay,
3:36:47it is renamed. And here also, it can
3:36:50give the response that okay, it is
3:36:52renamed. So, these two users will see
3:36:55two different data. This is not
3:36:56possible, right? And also, our leader is
3:36:59going to communicate with each other.
3:37:00So, this will send the request to update
3:37:03the data with C. And also, this leader
3:37:06will also send the same request to
3:37:08update it to B. Now, this is the
3:37:11conflict, and how do we resolve it?
3:37:12Basically, there are three ways of
3:37:14resolving it. The first way of resolving
3:37:17is the last right win. So, that is this
3:37:20right is performed, let's say, at this
3:37:23point, and this right is performed at
3:37:25this point. So, as this operation is
3:37:28performed later, so that means our L2
3:37:31needs to update our file to C. So,
3:37:35eventually, the file name will be C.
3:37:37This is our first approach. The second
3:37:39approach here is while working with
3:37:41different leaders, we assign some IDs to
3:37:43each and every leader. Suppose, leader
3:37:46one have ID 10, and leader two have ID
3:37:4911. Now, based on the ID, we can decide
3:37:52which leader is more powerful, and which
3:37:55leader we have to follow. Ultimately, if
3:37:58leader two is of higher ID, that means
3:38:00we have to follow leader two. And now,
3:38:02it doesn't matter if the last right was
3:38:04performed by L1 or L2. It is going to
3:38:07update it with the value of L2 only. So,
3:38:10here, instead of the last right, we are
3:38:12going to focus on the ID. So, we can say
3:38:15replica with higher ID wins. Replica is
3:38:19nothing but a replication. Like, every
3:38:22node which have the replica of content
3:38:24can be called replica. So, we can write
3:38:26leader also here. Okay, no issues. The
3:38:29third approach basically is the approach
3:38:31which we also see sometimes on Git when
3:38:33we try to solve merge requests. So, the
3:38:35same approach is used by the replication
3:38:37process as well. So, whenever there are
3:38:39conflicting situations, our leaders or
3:38:42any other nodes are not going to solve
3:38:44it. In this case, we will prompt our
3:38:46user directly that the file name has
3:38:49been changed to C and the last change
3:38:52which you have made was B. So, do you
3:38:54want to keep the current changes or do
3:38:56you want to update it to C? It is up to
3:38:59user. So, in this case, we need to add
3:39:01the application logic to basically pass
3:39:04our conflict to the users and eventually
3:39:06user will update it.
3:39:09After this, the third algorithm is
3:39:11leaderless replication. So, in this
3:39:14replication, we don't assign a specific
3:39:16leader to any data center or to any
3:39:19other node. We don't have any kind of
3:39:21leader in this leaderless replication.
3:39:24As the name suggests correctly, so here,
3:39:26what do we do? Here, let's say we have
3:39:29any client there. So, he is our user and
3:39:32now we have some databases. Let's say
3:39:34this is our node one, this is our node
3:39:36two, this is our node three. So, these
3:39:39are the three databases onto which our
3:39:42data needs to be replicated. So, this
3:39:44time whenever our user request for any
3:39:47update, let's say again this user is
3:39:49updating the profile picture, but this
3:39:52time the request basically goes to all
3:39:54of the nodes and eventually all will
3:39:57update the data and provides a response
3:40:01to the user. Here, the thing is in other
3:40:03applications where we had a leader, we
3:40:06can basically rely on that leader
3:40:08replica and based on the response which
3:40:10we get from leader, we can eventually
3:40:11decide that whether the operation is
3:40:13performed correctly or not. But here, we
3:40:15don't have any leader. So, what can we
3:40:17do? Do we wait for all the replicas to
3:40:20answer us and at this point we update
3:40:22our user or there is some other method?
3:40:25Let's talk about that in a bit, but
3:40:26before that, let's jot down some points.
3:40:29So, the first point here is we don't
3:40:31have any leader here. So, here we are
3:40:34bound to send our queries to more than
3:40:37one replicas, right? More than one
3:40:40nodes. So, every query, when I say every
3:40:43query, I mean both read as well as write
3:40:46queries, will go to multiple nodes and
3:40:49then collaboratively we'll get the
3:40:51response. When I say read also, that
3:40:54means let's say in this database only,
3:40:57if there is some other user who is also
3:40:58trying to access some values, and while
3:41:01accessing some values, the user can use
3:41:04this replica at this point or this
3:41:06replica at this point or this replica at
3:41:08this point. In all of these three
3:41:11scenarios, the user is going to get
3:41:13different values. So, here the user will
3:41:16get updated profile, and from here they
3:41:18will get the stale data. So, based on
3:41:20multiple entries, we have to decide
3:41:22whether to give this user updated data
3:41:24or the stale data. So, this is our
3:41:26struggle with this kind of replication.
3:41:28But, apart from the struggles which we
3:41:29see here, most of the applications in
3:41:32databases use this setup. It is used by
3:41:34various applications like Amazon Dynamo,
3:41:37Riak, Cassandra, VM. All of these use
3:41:40leaderless application. So, now the only
3:41:42issue is should we wait for each and
3:41:44every node to give us confirmation so
3:41:46that we can proceed to tell any user any
3:41:49response or is there any other way? So,
3:41:52as you may have guessed, definitely we
3:41:53can't wait for this long. There is a
3:41:56way. That way is basically termed as
3:41:58quorum. So, in quorum, what do we do?
3:42:00Suppose we have total number of nodes as
3:42:02three. We denote them by N, and for
3:42:06reading, we have to use more than half
3:42:09of the total nodes. So, it should be
3:42:11more than N by 2. Again, for writing, we
3:42:14should get the confirmation from more
3:42:16than the half nodes. This way we
3:42:18maintain the quorum and we will get the
3:42:21responses which we want for. So, in the
3:42:23same example, if I redraw it, suppose
3:42:26the user is again going to update any
3:42:28information, so updating profile picture
3:42:31again maybe, and the request went like
3:42:33this for first node, for second node
3:42:35maybe the network is faster here, and
3:42:38for the third node. Now, this is the
3:42:40time each node took in order to perform
3:42:43the operation. So, here we don't have to
3:42:45wait for this response because we
3:42:48already got the responses from more than
3:42:50the half of the nodes. So, we can easily
3:42:53say that profile picture is updated. So,
3:42:55here we can confirm that the operation
3:42:57of updating profile picture is done.
3:43:00Again, if a new user appears here, and
3:43:03the user is trying to access the value,
3:43:05so it can basically sends a read
3:43:07operation from these all nodes. Maybe at
3:43:10this point, maybe at this point. Suppose
3:43:13this point gives a result here, then
3:43:15this point also gives a result here. So,
3:43:17in these two responses, the user is
3:43:19getting different values because this is
3:43:21giving them stale data, and this is
3:43:23giving them updated data because the
3:43:25update is already done here, right? So,
3:43:27in this case, there are various other
3:43:29mechanisms also. You can go for
3:43:30timestamp, or they can go for any other
3:43:33mechanisms. But, let's say they don't go
3:43:35for any other mechanism. There is one
3:43:37more mechanism here where that is if the
3:43:39requests are equal, and we are still
3:43:41getting the different data, we will
3:43:43consider the third request and response,
3:43:46and then again calculate the results.
3:43:48So, here we are getting updated from two
3:43:51of the nodes, and we are getting stale
3:43:53value from one of them. So, we will move
3:43:56ahead with the updated value, and this
3:43:58user will get the updated profile
3:44:01picture. So, there can be various ways
3:44:03of solving this conflicts, but the thing
3:44:05is ultimately the user don't have to
3:44:08wait for each and every response. This
3:44:10is a special case where half of the
3:44:12nodes are saying that things are done,
3:44:14and half are saying things are not done.
3:44:15We don't have three servers also. We
3:44:17have more than 10 or 12 servers in a
3:44:20large system. So, this case becomes a
3:44:22rare case. So, yeah, this is all about
3:44:24the replication which we needs to know
3:44:26at this point. So, after replication,
3:44:28the other way of segregating our data
3:44:29into multiple nodes in order to scale
3:44:32them properly is partition. Now, before
3:44:35moving to partition, first see what can
3:44:37be the issue with replication.
3:44:39Replication basically suggests that we
3:44:41will copy entire data to other node.
3:44:43What if the data is so huge that we
3:44:45can't have them in one node? With this,
3:44:47the second concern is what if the data
3:44:50is so huge that even with secondary
3:44:52indexes, our time of searching any
3:44:55element is getting worse and worse. So,
3:44:58with these two concerns, we can't really
3:45:00have all of the data in one database and
3:45:03same data in other database. What can we
3:45:06do then? We can easily or through some
3:45:09logic break the system. We will do the
3:45:12partitioning of data and maybe place
3:45:14some amount of data here and other
3:45:16amount of data in some other node. And
3:45:19then, we can replicate this partition
3:45:21data. Why? Because this data is
3:45:23comparatively smaller and it will be
3:45:26easier to manage. Let's say, in a
3:45:28particular node, we are only saying that
3:45:31we will store up to 10,000 records. And
3:45:35then, once we hit this point, we will
3:45:37again create a new partition and will
3:45:40add the new records there. Or maybe
3:45:42divide these records into 5,000. So,
3:45:45these all things can be done only when
3:45:47we have a new way of partitioning the
3:45:50data. So, this is what partition really
3:45:52is. While partitioning the data, there
3:45:54is only a single rule. That is, if we
3:45:58are doing the partitions
3:46:00like this, then if we combine them, it
3:46:03should give us the entire data set. This
3:46:06is the only condition which is required
3:46:08for partition. And And makes sense, too.
3:46:11We don't want to lose any data, right?
3:46:13So, this is our first condition and the
3:46:15second condition is that let's say we
3:46:18have again two partitions. Now, we want
3:46:20our data to be equally distributed among
3:46:23them. We don't want any nodes to get
3:46:25let's say consumed by 90% of data and
3:46:28here we only have 10% of data because
3:46:31this basically beats the reasoning of
3:46:33partitioning. We are doing partitioning
3:46:34so that every node will be able to
3:46:37access some data and will be able to
3:46:39work frequently. So, basically we are
3:46:41saying that the data should be evenly
3:46:44distributed. So, these are the two major
3:46:47conditions of partitioning. Apart from
3:46:50this, everything works fine. So, the
3:46:51first condition makes sense. It will
3:46:53take care of itself and in order to
3:46:55fulfill second condition, we have to
3:46:56basically maintain some system where we
3:46:59will protect the database to get
3:47:01overloaded or to get underutilized like
3:47:04this. So, now let's talk about those
3:47:06solutions. So, the first thing here is
3:47:09we will partition using key. Let's say
3:47:12we have some table, maybe user table. We
3:47:14are handling these entities and then we
3:47:17have some ID here, user one or user two
3:47:21and the series goes like this. So, what
3:47:23we will do? We will basically in the
3:47:25partitioning based on the keys will
3:47:28insert the values. Let's say this user
3:47:30entity can hold up to 10,000
3:47:34or maybe 100,000 values. So, what we
3:47:36will do? We will divide these 100,000 to
3:47:3950,000 here and 50,000 here. So, that
3:47:41means from user one to user 50,000,
3:47:44these data will go to the node one or we
3:47:47can say partition one and the users from
3:47:51user ID maybe 50,000 one to user ID
3:47:55100,000 will go into partition two.
3:47:59So, this is how we will segregate our
3:48:01data so that it will be easier to
3:48:03retrieve the data afterwards as well.
3:48:05This may looks fair on the surface
3:48:07value, but it is quite messy. What if
3:48:10these users are from different regions?
3:48:13What if half of them from 1 to 50,000
3:48:17are from India and half of them are from
3:48:19US? Maybe here also they are distributed
3:48:22like this only. So, half of them are
3:48:24from India and half of them are from US.
3:48:27So, in that case, both of these nodes
3:48:29will be busy. This is a good scenario
3:48:31because both of the nodes will be used
3:48:33and will be busy in order to provide the
3:48:35information. And also it is possible
3:48:37that the node one is only taking care of
3:48:40India request
3:48:42and the US request are being taken care
3:48:44by partition two or node two. So, in
3:48:47this case what happens? Let's say the
3:48:49application is very popular in US, but
3:48:52is not that popular in India. So, maybe
3:48:55P1 is getting maybe 100 requests per
3:48:58second and on the other hand our
3:49:00partition two is getting maybe 10,000
3:49:03requests per second. Now, earlier this
3:49:06was looking good on the surface level,
3:49:08but now this is messy because one
3:49:10partition here is clearly becoming the
3:49:13hotspot. Now, what is hotspot? A hotspot
3:49:16is that partition which is getting more
3:49:18requests compared to other ones. So, it
3:49:22is our duty to maintain this hotspot as
3:49:24well. We don't want any node to become
3:49:27hotspot because eventually a hotspot can
3:49:30leads to the node failure. And if that
3:49:33node fails, we have to basically
3:49:35distribute the data into multiple nodes
3:49:37then and then do the configuration again
3:49:39or maybe change this node or maybe
3:49:42transfer this data to other node. All
3:49:44the things we have to manage, but that
3:49:46thing is surely not recommended. So, we
3:49:48avoid any node from becoming a hotspot.
3:49:52I hope this is making sense to you. So,
3:49:54one way of handling the hotspot is let's
3:49:58say for every request, we also attach
3:50:01timestamp and if most of these requests
3:50:04are going to node one and very less are
3:50:07going to node two, that means the data
3:50:10distribution which we did is not good.
3:50:13So, we have to rearrange our data with
3:50:16some other methods. So, let's see what
3:50:18the other points are. The second
3:50:20approach here can be partitioning the
3:50:23data with hash value of key. What we
3:50:27will do here is, let's say we have user
3:50:29one, user two, maybe user three as the
3:50:33ID or unique identifier of the data. And
3:50:36now we have to put that data into
3:50:38different partitions. We will not here
3:50:40choose ID, but we will use any hash
3:50:43function to basically transfer the ID to
3:50:46a unique number. Maybe this is one, this
3:50:48is two. And user three belongs to maybe
3:50:51one again because of the hash function
3:50:53which we are using. So, based on this,
3:50:55one and one will go to partition one and
3:50:59two will go here. Or maybe we are
3:51:01catering some range here, so maybe one
3:51:03to 10 can go into one direction and 10
3:51:06to 15 can go into other direction. So,
3:51:08this is also one way of doing the
3:51:10partition. The challenge here is still
3:51:12same. If the request bombarded at P1, we
3:51:16don't have any other way, but we have to
3:51:18rearrange like we discussed in the
3:51:20previous example. So, based on our
3:51:22discussion so far, the hotspot is
3:51:24becoming a real issue. Before solving it
3:51:27for partitions, let's first see how do
3:51:29we solve this issue in a local DB. Let's
3:51:32say we have a table for products. And in
3:51:35products, we have various attributes.
3:51:37Let's say we have some name and color or
3:51:40maybe price. We can have more filter
3:51:43values, right? And like this, we can
3:51:45have as many attributes as we want. So,
3:51:47name, color, price, material. All these
3:51:49attributes basically are used in order
3:51:52to filter these products. Name can be
3:51:54used in query parameters. Other than
3:51:57that, color, price, and range can be
3:52:00used in filter easily. So, what we will
3:52:03do in normal scenario? We will create
3:52:05indexes based on material, based on
3:52:08color, maybe based on price as well. I'm
3:52:11not sure about it because price normally
3:52:13goes into a range, but we can easily
3:52:16make a secondary index out of this and
3:52:19by that, whenever any user basically
3:52:22tries to search that particular product
3:52:24with material, maybe material is wood.
3:52:26So, what will happen? We will not go to
3:52:28our table or this huge table directly.
3:52:31Where we will redirect this query to, it
3:52:33is going to redirect it to our second
3:52:35query, which is maintained for material.
3:52:38And if that data or that value is here,
3:52:42we will then redirect those records
3:52:44particularly to our display. So, this is
3:52:47how we manage the queries to find out if
3:52:49we have the data or not, and if we have
3:52:51the data, where is that data
3:52:53particularly. This is how we solve it in
3:52:55local DB or a single instance. Now, we
3:52:58are going to use the same way into
3:53:00partitioning as well. So, what we are
3:53:02going to do? We are going to do the
3:53:04partitioning by the secondary index.
3:53:07What do we mean by this is, we are going
3:53:09to maintain secondary indexes in each
3:53:13partition. So, that means all the
3:53:15secondary indexes will be present in
3:53:18each partition respectively. This way is
3:53:21also used by Cassandra and also by
3:53:24Elastic Search. What we are going to do
3:53:26here is, let's say this is our partition
3:53:28one, which have some data. Maybe this
3:53:30partition have car data from ID, let's
3:53:34say 200 to 400. And we have partition
3:53:37two, where also we have some car data
3:53:40from ID, let's say 500 to 700. Here, we
3:53:45are maintaining some secondary indexes.
3:53:47Maybe we are maintaining color as a
3:53:49secondary index. And for color, we know
3:53:51that the blue color is for car maybe
3:53:54with ID 209 and 305. Similarly, for red,
3:53:59we can say the ID is 350
3:54:03or 359, anything, right?
3:54:07For P2 also, we are maintaining it like
3:54:08this only. Again, for color, we know
3:54:11that the blue color cars are maybe ID
3:54:14509
3:54:15and 609 and red cars are 610 690. So,
3:54:21these are the indexing which is done in
3:54:23both of these partitions. So, whenever a
3:54:25query comes for a blue car, we don't
3:54:28have to scan to all the records, but we
3:54:31can directly see the blue car here
3:54:33belongs to 209 and 305. And here, we
3:54:37have blue car for 509 and 609 only.
3:54:40Let's say a new request come for silver
3:54:43car. So, we don't have to basically
3:54:46indulge into all the records, but by
3:54:48seeing secondary indexes on color only,
3:54:51we will get that this partition doesn't
3:54:53have any car which is of silver color.
3:54:55So, we don't scan this partition
3:54:57entirely and this request can now go to
3:55:00some other partition. So, this is how we
3:55:02are maintaining the request so that our
3:55:05data doesn't get overloaded with a lot
3:55:07of request, but based on the request, if
3:55:10they are present in our secondary
3:55:11indexes, then only we will entertain
3:55:13them and show them the records or fetch
3:55:15some records, otherwise, we will
3:55:17directly skip them. Now, this kind of
3:55:19setup also have its challenges, right?
3:55:21Because partitioning is done, but
3:55:24secondary indexes are also present in
3:55:27each partition. That means even if the
3:55:30partition doesn't have any value, we
3:55:33still have to send a request to that
3:55:35particular partition. This is again a
3:55:37drawback of the system which can make
3:55:39the system heavy, which can send the
3:55:41request to many partitions where the
3:55:44data is not there and we are still
3:55:45getting the request. So, this is also
3:55:48wrong. So, that's why we have a fourth
3:55:50and final way of solving this, which is
3:55:53by having common global index. What we
3:55:57will do here is instead of having
3:55:59secondary indexes in each and every
3:56:01partition, we will choose a partition or
3:56:04any data center where we will maintain
3:56:07the secondary indexes. So, if we are
3:56:10saying that we want the car with color
3:56:13blue, we should know that blue car
3:56:15colors, according to the previous
3:56:17examples, are only 209305
3:56:20and here we have 509 and 609. And
3:56:23basically, this belongs to our P1 and
3:56:26this belongs to our P2.
3:56:28So, we should know this first-handedly.
3:56:31So, that whenever anyone is requesting
3:56:33to get any information about blue color
3:56:35car, we will directly redirect it to P1
3:56:39and P2. And suppose we have some other
3:56:41partitions, P3, P4, and others, we don't
3:56:46send the request there. So, that these
3:56:48partitions can take care of other
3:56:50requests. So, this is our fourth way of
3:56:53maintaining the global index. So, with
3:56:56this, definitely, we are going to
3:56:57improve our reading, but the writing
3:57:00becomes a challenge. Why? Because even
3:57:03if we are working with partition 79,
3:57:06where we are adding some values, and
3:57:08again have to update that, "Okay, we
3:57:10have some new car, maybe 1011, which is
3:57:13of blue color." So, like this, it is
3:57:15handled. So, these are the ways of
3:57:18handling partitioning into our system.
3:57:20After understanding about partitioning,
3:57:22replication, and load balancing, we now
3:57:25know that we need to segregate our data
3:57:27into multiple nodes in order to scale
3:57:30them. We can't scale them into a single
3:57:33database after an extent. So, after
3:57:35understanding this, let's see what CAP
3:57:38theorem basically says.
3:57:40CAP theorem is one of those theorems
3:57:42which we have to know whenever you think
3:57:45about trade-offs between capacity and
3:57:47availability. So, first see what CAP
3:57:49theorem really stands for. In CAP
3:57:52theorem, there are three terms
3:57:54basically. C stands for consistency,
3:57:57whereas A stands for availability, and P
3:57:59stands for partition tolerance.
3:58:02So, CAP theorem basically states that
3:58:04you can only provide two of these three
3:58:07variables, which means if we talk about
3:58:10consistency, what does it mean?
3:58:12Consistency basically means providing
3:58:14latest information to every user.
3:58:17So, consistency stands for latest
3:58:19information. Now, if we are providing
3:58:21latest information, let's see what it
3:58:23really means. Let's say this is our
3:58:25partition one,
3:58:26this is our partition two. Some data is
3:58:29updated on partition one,
3:58:32and someone is reading that data
3:58:34immediately after the update. So, this
3:58:37update from partition one and partition
3:58:40two will also take some time. And at
3:58:42that time, we basically show something
3:58:45like system is loading or data is
3:58:47loading kind of thing to user until the
3:58:50change is completed on P2. Then only we
3:58:53can show the latest data. So, this means
3:58:55that we will trade off our availability
3:58:58of that particular information for
3:59:00consistency. The second thing is
3:59:02availability. Availability basically
3:59:04states that we will always respond to
3:59:08every request. Now, what does this mean?
3:59:10In the same scenario, if it is taking
3:59:13time to upload a data from B1 to B2, and
3:59:16while updating someone request in
3:59:18between, so they will not see loading
3:59:20icon. Instead, they will see the stale
3:59:23data. So, this is what availability
3:59:25means. Now, the third term, which is
3:59:27partitioning. Partitioning, we all know
3:59:29now we need to divide our data into
3:59:32multiple nodes, right? Now, with
3:59:34partition, we can also see tolerance
3:59:36here. What does it mean? Let's say there
3:59:38are some nodes attached or linked to
3:59:41each other. Now, this is partition
3:59:44tolerant when the network of this node
3:59:47is completely broken. So, this can't be
3:59:50updated from any other method. We can
3:59:52either wait to basically fix this
3:59:54partition connection and update the
3:59:56value or we can keep it working to
3:59:58provide the information. But, then the
4:00:01information we are going to provide is
4:00:03going to be stale data. Why? Because the
4:00:05connections between this node and the
4:00:07other nodes are broken. Now, let's talk
4:00:09about the combinations one by one. So,
4:00:11first combination is CA,
4:00:14which means we are saying that our data
4:00:16will be consistent and it will be
4:00:18available also. In this case, we can't
4:00:21provide the partitioning part. Because
4:00:23if we are saying that our data is
4:00:24consistent and available, that means we
4:00:27are maintaining a single database. We
4:00:29can't basically have two data centers or
4:00:32two nodes and think about consistency
4:00:35and availability at the same time.
4:00:36Suppose we have updated any data here,
4:00:38it is going to take at least some
4:00:40fraction of time to update the data to
4:00:42other node. So, in that meantime, if
4:00:45someone request about that particular
4:00:47data, we can't decide basically whether
4:00:49to show that data or node. Because if we
4:00:52show that data, that means we are
4:00:53compromising our consistency there. And
4:00:56if we don't show that data and wait for
4:00:58the update, that means we are
4:00:59compromising with the availability. So,
4:01:01this combination is only possible when
4:01:05we are working with a single database or
4:01:06a single node. We can't do partitioning
4:01:09here. With this, let's move to our
4:01:10second combination,
4:01:12which is CP. CP means we are choosing
4:01:15consistency over availability. So, here
4:01:18we are saying consistency and
4:01:20partitioning will be there, but we'll be
4:01:22trade-off availability. Now, we have
4:01:24understood this term, let me take the
4:01:26example again. These are our two nodes
4:01:28and the partition happens. Basically,
4:01:31the connection between these nodes
4:01:32break. Now, this doesn't have the
4:01:35updated value. Now, when we are choosing
4:01:37consistency, we have to let go of the
4:01:39availability. So, we are saying no
4:01:42request will be processed by this node.
4:01:44Until when? Until it gets updated with
4:01:47the latest data. So, this is what
4:01:48happens when we are working in a
4:01:50partitioned environment and choose
4:01:51consistency over availability. That
4:01:53means the requests which are calling
4:01:55this node will be redirected to some
4:01:58other nodes which have the latest or
4:02:00consistent data. With this, let's see
4:02:02the third combination as well, which is
4:02:05AP. In AP, we are providing availability
4:02:08to every request, right? So, we are
4:02:10providing availability with
4:02:12partitioning. So, what is going to
4:02:14happen here? When there are two nodes
4:02:17and the partition tolerance happen, that
4:02:19means this node doesn't have updated no
4:02:22updates. At that time also, because we
4:02:25have chosen availability over
4:02:26consistency, we will keep addressing the
4:02:28request by showing them the stale data.
4:02:31And that means we are compromising with
4:02:33consistency. So, why are we learning
4:02:35this CAP theorem? The CAP theorem
4:02:37basically states that you have to do
4:02:39some trade-offs in order to keep your
4:02:41application working. Suppose we are
4:02:44working on Instagram. In Instagram, the
4:02:46availability matters over consistency.
4:02:48Suppose you have updated a video or a
4:02:50photo, it doesn't matter for your
4:02:53followers to see that photo immediately.
4:02:56They can wait for 1 or 2 seconds
4:02:57basically. So, in Instagram, we will be
4:03:00following AP. But in any application,
4:03:03let's say banking application, where
4:03:05each transaction matters to us, where
4:03:07each change matters to us. So, if I have
4:03:10sent 100 rupees to any other account,
4:03:13the person will have to wait in order to
4:03:16process that transaction, and after that
4:03:18only they will be able to see. So, here
4:03:21CP matters. And for CA, CA will be there
4:03:25if we have a single data. That means for
4:03:27every small application, CA can work.
4:03:30But when the system scales, we don't
4:03:32have an option to pick CA. That's when
4:03:34we have to choose between consistency
4:03:36and availability. So, this is what CAP
4:03:38theorem is. I hope you all understand
4:03:40it. Now, let's understand one of the
4:03:42most important component of our system
4:03:44design, which is message queue. Now,
4:03:46before going into depth of message
4:03:48queue, let's first understand the type
4:03:50of request we deal with. We normally
4:03:52deal with two type of request. Or we can
4:03:55also say requests or maybe processes.
4:03:58Some requests are sync. That means
4:04:01whenever the request is received, we
4:04:03have to immediately provide them some
4:04:05output or response for the system to
4:04:08keep working. On the other hand, we have
4:04:10async calls, requests, or processes in
4:04:13which we get the request, but there is
4:04:15no hurry for our responses. Also, it is
4:04:19also possible that we don't give any
4:04:21response at all. So, so that means our
4:04:24system only
4:04:26takes the request and basically fulfill
4:04:29the requirement in the backend
4:04:30processes. So, in case of sync type of
4:04:33calls, requests, or processes, we can't
4:04:35do anything. Our system needs to be
4:04:38concentrated on these requests and have
4:04:41to provide the responses as soon as
4:04:43possible, which we have discussed
4:04:45throughout these courses. Now comes the
4:04:47second part, which are async requests.
4:04:49So, let's understand async process or
4:04:51request with some example. Let's say we
4:04:54are an e-commerce application. We have
4:04:57some store, maybe some product is there,
4:05:00and finally someone purchased this
4:05:01particular product. So, at the time of
4:05:04purchase, what are the operations we
4:05:06need to perform? First is, we need to
4:05:08send some email to the user that order
4:05:11is confirmed and here are your details.
4:05:13We have to also update the inventory so
4:05:16that if, let's say, only one product is
4:05:19left, that product should immediately be
4:05:21out of stock so that there will be no
4:05:23confusion for any other record. Other
4:05:25than this, we also have to inform our
4:05:27delivery partner, right? So, that they
4:05:29will start packaging and moving the
4:05:31order further. Now, out of these three
4:05:33processes or request, which do you think
4:05:36is the most immediate action? So, let's
4:05:39see. Updating inventory is one of the
4:05:42crucial task which have to be performed
4:05:44immediately. We can't wait for it,
4:05:45right? Otherwise, it can create
4:05:47blunders. So, this is definitely a
4:05:50synchronous task. But, other than that,
4:05:53we can use some third-party email
4:05:55service to process the email, right? We
4:05:58don't have to send the emails
4:05:59immediately. Even if the email goes,
4:06:02let's say, 1 minute late, that is also
4:06:04fine, and our system will be keep
4:06:06working.
4:06:07Similarly, for delivery, we can say that
4:06:09delivery also is an async operation
4:06:12because we are not in any hurry. Also,
4:06:14our system doesn't need to take care of
4:06:16delivery, as well. So, we will simply
4:06:18pass this information to any delivery
4:06:20service, and our current system can
4:06:22basically focus on some other task. So,
4:06:25this is how a distributed environment
4:06:27works. Basically, we have multiple
4:06:30services who communicate with each other
4:06:33in order to fulfill the requirement. So,
4:06:35if the services are different, and we
4:06:38have to use, let's say, email, with
4:06:39email, we can also use
4:06:41SMS service, or maybe WhatsApp service.
4:06:45We can use them, and these all are async
4:06:48kind of calls. We don't have to stop our
4:06:51system in order to process this request.
4:06:54So, I hope up to now we have understood
4:06:56about async and sync kind of request,
4:06:59and in async, why we can use some other
4:07:01services, and for sync, we have to wait
4:07:04for the response in order to show some
4:07:06immediate data, like out of service
4:07:08product. Now, let's talk about some of
4:07:10the examples for sync. Every financial
4:07:13application can be an example here.
4:07:15Wherever we are concerned about
4:07:17security, we can't rely on async kind of
4:07:20operation. We have to basically provide
4:07:23the communication immediately. The third
4:07:25area can be dependent. Wherever there is
4:07:28a dependency on one or the other task to
4:07:31be performed after a particular task in
4:07:33a synchronous manner, we have to
4:07:35complete this task in a synchronous
4:07:37manner.
4:07:38So that the dependent processes can also
4:07:41work. For example, we can't process any
4:07:43emails for order details before
4:07:46processing the order. Once the order is
4:07:48processed and confirmed, then only we
4:07:51can put down the emails or other
4:07:53notifications. So after this, let's talk
4:07:55about async also. Async request
4:07:58basically works wherever we need to
4:08:00simply fire our request and our system
4:08:03can then forget about that. So this is
4:08:06the golden rule to understand what
4:08:08system is async or what request is async
4:08:11versus sync. Whenever we get the feeling
4:08:14or we get the components where we can
4:08:16simply fire a request and then our
4:08:18system can forget about that, we can
4:08:21easily move to async calls, which will
4:08:23not only speed our systems but also free
4:08:26our system in order to work on different
4:08:28tasks. So some examples on free and
4:08:31forget can be broadcasting. Broadcasting
4:08:33can be of anything like email
4:08:35broadcasting, even the matches, the live
4:08:37matches which we see online on any
4:08:39application, there also we can feel some
4:08:42latency. The latency can be from 0
4:08:44seconds to 7 or 8 or 10 seconds also
4:08:47based on the network connections you
4:08:49have. So broadcasting we have discussed,
4:08:51email we can write here. Also we have
4:08:53seen
4:08:54SMS
4:08:56or WhatsApp. Basically any communication
4:08:58can be held asynchronously. Also the OTP
4:09:01applications. In all the OTP
4:09:04application, there is a timer and that
4:09:06timer is mostly more than 30 seconds.
4:09:09Why? Because in 30 seconds our system
4:09:12can handle this request in an async
4:09:14manner. So, now we have understood sync
4:09:16and async, let's talk about message
4:09:18queues. In order to understand message
4:09:20queue, let's take the same example. So,
4:09:22this is our e-commerce application and
4:09:25we are using the service for emails.
4:09:28Now, on our e-commerce application, we
4:09:30are getting some order and based on that
4:09:33order, we have to send emails.
4:09:35But, in between, we will implant message
4:09:38queue. In diagrams, message queue is
4:09:41denoted like this because it is
4:09:42basically a queue
4:09:44and each of these order request or email
4:09:47request can be hold in the message queue
4:09:49and then through our message queues, it
4:09:52can go directly to our email services.
4:09:55So, what our application needs to do, it
4:09:58will simply dump all the email request
4:10:01to our message queue and from there, the
4:10:03message queue will take care of those
4:10:04requests. It is like a buffer or we can
4:10:07say broker in between two apps or
4:10:09services. Now, whichever party or
4:10:12application is putting the request into
4:10:15message queues are known as producers
4:10:18and whichever service is taking the
4:10:21request from message queues are called
4:10:23consumers. With this, producers can also
4:10:26be called publishers and consumers can
4:10:29also be called subscribers because
4:10:32publishers are publishing the message to
4:10:34message queue and then subscribers are
4:10:37the message who are subscribed to take
4:10:39those request from our message queue.
4:10:42So, this is how a message queue
4:10:43basically works. You may think now that
4:10:46why are we using message queue? Can't we
4:10:47directly call the consumer or the email
4:10:50service from our application? Yes, we
4:10:52can call, but that will keep our system
4:10:55busy. We don't want to keep our system
4:10:57busy and we also want that whatever
4:10:59request we are sending should be taken
4:11:01care by. So, these two things can only
4:11:04be done by a message queue. Now, if we
4:11:07talk about qualities of message queue,
4:11:09before writing the qualities, I just
4:11:11want to say that if you still don't get
4:11:13what message queues are, just bear with
4:11:15me for some minutes and you will be
4:11:16absolutely get why do we use message
4:11:19queues. So, the first quality here is
4:11:21that our message queues can basically
4:11:24hold the request. With holding the
4:11:26request, our message queues will have to
4:11:29communicate those requests to our
4:11:31servers. So, they can communicate to
4:11:33servers or we can say services here.
4:11:36With this, why do we use message queue?
4:11:38The reason is it can also be used to
4:11:41handle the failed calls. And with this,
4:11:43one of the major reason of using message
4:11:45queue is handles the load which we are
4:11:47giving to the third party or the service
4:11:50application here, email service. At this
4:11:52point, let's talk about direct
4:11:54communication again. If we again send
4:11:57the request directly from our e-commerce
4:11:59application to email services, that
4:12:01means every time a new order is placed,
4:12:03this call is going to be there. If our
4:12:06email server is down or anything, that
4:12:08call is going to handle the failure case
4:12:10also. That will be responsibility of our
4:12:13e-commerce application. But now, since
4:12:15we are using message queue, these both
4:12:17queries and these both troubles will be
4:12:20handled by our message queue itself. So,
4:12:22we don't have to care about the failed
4:12:24request also. So now, what happens is
4:12:26there are various ways of sending
4:12:28request from message queue to the
4:12:30server. Normally, our message queues
4:12:32follows FIFO. We all know about FIFO.
4:12:35FIFO basically means first-in,
4:12:37first-out. That means whatever request
4:12:40comes first will be delivered first to
4:12:43our consumer. And this is how the series
4:12:46will follow. So, in this case, the first
4:12:49request will be taken care and then
4:12:51after that second, after then third, and
4:12:54so forth.
4:12:55So, this is what the first-in, first-out
4:12:56principle is and it is used by our
4:12:58message queue in order to process the
4:13:00request. So, in FIFO, we have two
4:13:03approaches. First is
4:13:05strict order approach, which basically
4:13:07means, let's say this is our message
4:13:08queue again,
4:13:10and while processing the orders or
4:13:12requests, let's say first process is
4:13:14processed by our consumer, done.
4:13:17After that, we'll come to the second
4:13:19one. So, the second one is also
4:13:21processed.
4:13:22Then, while processing the third
4:13:24request, it breaks down. So, maybe
4:13:26something is wrong with the request or
4:13:28maybe our consumer is down for some
4:13:30time. Because of any reason,
4:13:33our request was not processed. So, if we
4:13:36are following strict order, even if
4:13:39anything fails at this level, our queue
4:13:42will not proceed. Our consumer, even if
4:13:45it starts working again, can't process
4:13:47the fourth request. So, this is not
4:13:50recommended at all because of obvious
4:13:52reasons, because we want our process to
4:13:55keep continue even if one or other
4:13:57request fails.
4:14:00So, the second part solve this issue,
4:14:02which is unordered queue. So, in
4:14:04unordered queue, what we'll do, we'll
4:14:07again create like this only structure of
4:14:10our message queue. So, every time our
4:14:12consumer or subscriber
4:14:14takes back our request, so one, two, and
4:14:18even if there is some issue with the
4:14:20third request, our system will jump to
4:14:23the other request in order to fulfill
4:14:25that. So, our consumer will get the
4:14:27request to perform the operations. Our
4:14:29system will not break. What will happen
4:14:32to the third request? Let's talk about
4:14:33that in a bit. So, after unordered
4:14:36queue, it is also possible that the
4:14:38things which we are getting
4:14:40in request in the message queues, maybe
4:14:43our first request, second request, third
4:14:45request, and fourth request,
4:14:48between all of them, our fourth request
4:14:50is like very important to us, is of high
4:14:54priority, and maybe second request is
4:14:56also of high priority, but not first and
4:14:59third. So, in this case we can't follow
4:15:01FIFO principle, right? So, our consumer
4:15:03needs to get the second and the fourth
4:15:05request first. This is where we used
4:15:08priority queue.
4:15:09What we will do, we will attest a
4:15:11priority
4:15:12like number or some ID to every call.
4:15:16And whose priority is higher, those
4:15:18calls will be picked first by the
4:15:20consumers. So, in this structure if we
4:15:22talk about if the priority of every call
4:15:26is set, let's say the priority of first
4:15:28call is 10, the priority of second call
4:15:31is maybe three, the priority of third
4:15:33call is eight, and priority of fourth
4:15:35call is one. So, that means the first
4:15:39call which our C is going to cater is
4:15:42fourth one.
4:15:43After fourth, it will cater the second
4:15:45call. After second, it will cater the
4:15:48third call, and after third, it can
4:15:50cater the first call. Also, these
4:15:53numbers are in ascending order. I have
4:15:55created uh my system in that way that
4:15:58one will be the most important priority
4:16:00request, but you can reverse the order
4:16:02as well. So, this is how our priority
4:16:05queue is going to take request. After
4:16:07understanding priority queue, there are
4:16:09two more concepts here.
4:16:11So, the one concept is pull request. So,
4:16:14in pull request or pull-based request,
4:16:16what happens is whenever we have some
4:16:19data in our queue, let's again put 1 2 3
4:16:23or some random values. Now, these
4:16:25requests are in queue, which means that
4:16:28the queue message queue will take care
4:16:30of them.
4:16:31But, the consumer here will decide when
4:16:35to pick the request. Maybe our consumer
4:16:37is working with some other task, and the
4:16:39moment it gets free, it can pull the
4:16:42request. So, message queue will not send
4:16:45the request to consumers. Our consumer
4:16:48will pull the request accordingly.
4:16:50Again, the reverse of this is push-based
4:16:53request. In push-based request, what
4:16:55happens is the opposite of pull-based
4:16:58request, which means if we have some
4:17:01request in our queue, our message queue
4:17:04is going to start the communication with
4:17:07consumer and going to push our request
4:17:09to the consumers. So, here the
4:17:11communication starts from message queue,
4:17:14and in the previous case of pull-based,
4:17:16it will start with consumer. Also, I can
4:17:18change the
4:17:20uh direction of our request.
4:17:22So, because it is pulling, so request
4:17:24will come from here. So, I hope up to
4:17:27now the things are clear.
4:17:28Now, let's talk about pub/sub models.
4:17:31So, in pub/sub kind of architecture,
4:17:33what normally happens is we have
4:17:35publishers here who are like sending the
4:17:38message to our message queue.
4:17:40We have message queue in between,
4:17:42and here we can have multiple
4:17:43subscribers as well. So, what we are
4:17:45going to do, these publishers are going
4:17:48to send some or the other message to our
4:17:50message queue, which will be taken care
4:17:52by our message queue by providing them
4:17:54to the subscribers. Maybe this is using
4:17:56push, and this is using pull. So, this
4:17:59is how the system works in pub/sub
4:18:01model. Pub/sub is nothing but the
4:18:03understanding of our message queues
4:18:05only. So, in this model, we include
4:18:07subscribers
4:18:09and publishers as well. Now, as
4:18:11discussed in the previous example, our
4:18:13message queue needs to perform some
4:18:15operations in pub/sub model as well.
4:18:17First thing is it will hold the request.
4:18:20It will send these requests one by one
4:18:22to the subscribers. And also, in case of
4:18:26any failed response, message queue needs
4:18:29to take care of that. With this, our
4:18:31message queue is also responsible in a
4:18:33way to take care of subscribers as well.
4:18:36By taking care, I mean our message queue
4:18:38needs to check subscriber is working or
4:18:41not. If it is not working, our message
4:18:43queue will not send the request to that
4:18:46particular subscriber, and it will
4:18:48redirect the request to maybe some other
4:18:50subscriber. This is how the things work.
4:18:52So, our message queue basically
4:18:54maintains or the whole state of the
4:18:57request as well.
4:18:58Send the request to subscribers. Take
4:19:01care of the failed request by using DLQ.
4:19:04We will see that in a minute. And also
4:19:07take care of the subscribers health.
4:19:09Also keep checking whether the
4:19:10subscriber is it still alive to work or
4:19:13not. We can also say that it's still
4:19:15alive or not. We can also say that our
4:19:17message queue takes care of request and
4:19:19takes the response from subscribers as
4:19:22well. So, that means our message queue
4:19:23know which subscriber is working fine or
4:19:26fast and which is not working that
4:19:28delicately. So, every time we get a
4:19:31priority queue or a priority task, it
4:19:33will be sent to the subscriber who is
4:19:35working efficiently. So, this is what
4:19:37Pub/Sub basically is. Let's talk about
4:19:39some of the factors which can affect
4:19:41Pub/Sub. The first thing which you can
4:19:43talk about is message order. Let's talk
4:19:46about message order. So, we are saying
4:19:48that all the calls which are going to
4:19:50message queue are async calls. Then why
4:19:53do we need to maintain order? Okay.
4:19:55First thing is that even if we want to
4:19:57maintain some order, we know that we can
4:20:00use priority queue.
4:20:01And this is the only way of maintaining
4:20:03any kind of order in message queue.
4:20:05There is no other way. Maybe it is
4:20:07handled by our application or maybe we
4:20:09can add some additional information of
4:20:11order in the request itself. This is how
4:20:14we can handle message orders. Other than
4:20:16that, it is for async calls where the
4:20:19order doesn't matter. The second thing
4:20:21we can talk about is how our messages
4:20:24are going to be consumed. So, we know
4:20:26that publishers publish the message and
4:20:29they will store in message queue and
4:20:30consumers are going to consume this. But
4:20:32how they are going to consume this? We
4:20:34are not maintaining any order. That
4:20:36means these consumptions are random.
4:20:40Maybe out of 100 request, the consumer
4:20:43can pick up the 100 requests first. Even
4:20:46if we are using priority queue, we can
4:20:48make the priority of 100 requests first.
4:20:50So, there is no particular order in
4:20:53which the requests are going to be
4:20:54fulfilled.
4:20:55Consumers can pick any of the request
4:20:58anytime. Also, message queue can send
4:21:00any of the request anytime based on the
4:21:02priority either or it is completely
4:21:05random. Let's talk about the third
4:21:06factor, which is poison message. So, all
4:21:10the poison messages means all the
4:21:13messages that subscribers are not able
4:21:16to process. Maybe because they are bad
4:21:19requests or maybe invalid. It is also
4:21:23possible that they are failing like
4:21:25after multiple returns as well. Also, if
4:21:27we think about it, let's say a request
4:21:30failed at the consumer side. And then,
4:21:32if we send those requests again and
4:21:34again, those are going to use or consume
4:21:37the consumers energy and will do
4:21:39nothing. Those requests are basically
4:21:41our poison request who are taking time
4:21:44and resource from our consumer as well
4:21:46as message queue but are not able to
4:21:47fulfill. Now, at this point, let's talk
4:21:50about DLQ. So, this is our message
4:21:52queue. This is our publisher or
4:21:54producer, we can say. And here, we have
4:21:56our consumer or subscriber. Now, let's
4:21:59say we have a request which has not been
4:22:02processed by our subscriber due to any
4:22:04of the reasons. So, in this case, our
4:22:07message queue can't stop. It will send
4:22:09the next request. But, this first
4:22:12request will go to a different queue for
4:22:15retry or to maintain that this request
4:22:18was failed. This queue basically, which
4:22:21is maintained by our message queue only,
4:22:23is called DLQ. DLQ stands for dead queue
4:22:27or dead letter queue. So, our message
4:22:30queue maintains this DLQ in order to
4:22:32keep track of the failed request as
4:22:34well.
4:22:35So, that even if the publisher have put
4:22:38the async operations, eventually
4:22:41they will have to know that these cases
4:22:43are failed. So, we will see the failed
4:22:45logs or failed requests through any
4:22:47logs, from which we will see, "Okay,
4:22:50this request was failed."
4:22:51Or other than that, we can also send
4:22:53some or the other information to our
4:22:55publisher in a async manner or in a
4:22:58report kind of manner, where we will
4:22:59give the stats of these many requests
4:23:01are passed, these many requests are
4:23:03failed. And here are the reasons of the
4:23:05failed request. So, this DLQ is the
4:23:08mechanisms through which our message
4:23:10queue will take care of the failed
4:23:12requests as well. I hope you get it now.
4:23:15Also, poison. Poison means any request
4:23:18which can't be processed, which is using
4:23:20or consuming the resources, but can't be
4:23:22processed.
4:23:24So, with this, let's move to our four
4:23:26factor. Fourth factor basically is
4:23:29duplicacy. So, if, let's say, our
4:23:32message queue have processed this
4:23:35request when it is already processed by
4:23:37subscriber one, then it should not
4:23:40travel to subscriber two by any other
4:23:43way.
4:23:43Because the request is already
4:23:45processed, it should not be processed
4:23:47again. What if this request contains
4:23:50some important information which can't
4:23:52be done twice? So, in order to maintain
4:23:55duplicacy, our message queue only takes
4:23:58care of this thing.
4:23:59So, with taking care of each request and
4:24:03dead request, it is also duty of message
4:24:06queue that whenever a process is done,
4:24:09it should be deleted from our message
4:24:11queue, so that we don't perform any
4:24:13operation on that particular request. It
4:24:15should be deleted. And if configured,
4:24:18our message queue keeps end track of
4:24:20this, that there was some request which
4:24:22was obtained from P1 producer
4:24:25and was handled by our S1 subscriber.
4:24:28So, this is how our message queue will
4:24:30take care of the duplicacy of the
4:24:32request as well. After discussing all
4:24:35these things, let's talk about some of
4:24:36the use cases. Like where we can use
4:24:39message Q easily and where we should
4:24:41avoid using message Q. Let's say if we
4:24:44are working on any async kind of
4:24:46environment, any async operations, any
4:24:49async request, we can easily go for
4:24:52message Q. There is no doubt about that.
4:24:54Similarly, if we talk about any
4:24:56decoupling activity, which can be like
4:24:59taking care of user analytics we want to
4:25:01see and capture, maybe we want to
4:25:02capture where our user lands, if our
4:25:05order is failing, why they are failing,
4:25:07and all the log systems. We can easily
4:25:09do this with our message Q as well.
4:25:12There is no doubt about this.
4:25:14The third area can be our load balancing
4:25:17acts. So, if we think about it, our
4:25:19message Q does everything what a load
4:25:22balancer does, right? So, our message Qs
4:25:25can be used as load balancers as well.
4:25:29Where it will take care of all the
4:25:31request, it will keep them in a Q, and
4:25:33it will provide those requests to
4:25:35servers respectively.
4:25:37Also, we can use the message Q with this
4:25:39with the deferred system. Where we have
4:25:42some operations, but we can basically do
4:25:44them later, like generating reports and
4:25:47everything. After every day, we can
4:25:49generate some reports. Or maybe there
4:25:51can be any schedule processes for doing
4:25:53anything. Let's say we are adding
4:25:55products into our catalogs like whole
4:25:57day, and in the evening we want them to
4:25:59be live. So, we will schedule a process
4:26:01in order to work with them. So, the
4:26:03message Qs can be used with load
4:26:05balancer as well as they can be used by
4:26:07our deferred system. Now, message Qs are
4:26:10a costly service. So, if we don't have a
4:26:13lot of request, we should not use
4:26:15message Qs, right? Because it is a
4:26:17costly service, and why waste our cost
4:26:21when we can use them in a synchronous
4:26:22manner? Or maybe if the request count is
4:26:25low, we will directly call the
4:26:27subscriber from producers. Like for
4:26:29emailing, we will directly send the
4:26:30request for our email service. With
4:26:33this, if we are using any real-time
4:26:35application, we can't use message queues
4:26:37basically. Why? Because we need the
4:26:40response to be in a synchronous manner.
4:26:42We need the response to be immediate.
4:26:44And if we are using message queue,
4:26:46our request can take some time
4:26:49to basically respond from any email
4:26:51service or any other services which we
4:26:53are using. So, in these cases, we should
4:26:55avoid using message queues. And also, we
4:26:57should avoid using message queues
4:26:59whenever we need some acknowledgement.
4:27:04Because if we need some acknowledgement,
4:27:05that means our server or our system is
4:27:09waiting for the some response to get.
4:27:11But message queue normally doesn't do
4:27:12it. In this example, where we were
4:27:14sending some reports, this will be also
4:27:17done by some or the other intervention
4:27:19of our code only, so that we can see the
4:27:21processes. But if we want response from
4:27:23every request, it can't be done by
4:27:25message queue. So, whenever we need
4:27:27acknowledgement, we don't use message
4:27:29queues here. And with this, we have
4:27:31covered about message queues. Now, let's
4:27:33talk about faults. Whenever we think
4:27:36about faults or error, we basically,
4:27:39while building any system or while
4:27:41building any software as well, we have
4:27:42to take care of each and every fault and
4:27:44error. Now, while studying system
4:27:46design, we have encountered very
4:27:48components and we know what the
4:27:50complexity our software also holds. So,
4:27:53let's talk about faults and error. So,
4:27:55our faults or errors can be called as in
4:27:58any condition, if our system is not
4:28:01responding in a way it should respond,
4:28:03that means we have some issue or some
4:28:06fault or some error with our system. We
4:28:09can easily categorize them into three
4:28:11categories. The first category is
4:28:13hardware. So, hardware faults are
4:28:15basically belongs to our server. Maybe
4:28:18we are using databases, so DB can also
4:28:20crash.
4:28:21We are using message queues, we are
4:28:23using each and every components, and
4:28:25every component can fail our system if
4:28:27they stops working. So, this hardware
4:28:30issue or hardware fault is our first
4:28:32type, and the nature of our hardware
4:28:34failures is it can be random, right?
4:28:37Like our system can fail entirely
4:28:39anytime. There can be various reasons of
4:28:42its failure. We can have like a disk is
4:28:44full or something out of memory issue,
4:28:47or let's say our server is down. We also
4:28:49use network cables, so maybe they are
4:28:51damaged. Maybe there is an issue with
4:28:54the power supply. Maybe one or the other
4:28:56node is not configured correctly, or
4:28:58maybe it is experiencing some spike in
4:29:00request, so it is down because of
4:29:02overheating. Also, we are using
4:29:04databases, so database can also be
4:29:06compromised, right? These all things are
4:29:08basically the fault of our hardware. We
4:29:11do have some control over it, like we
4:29:12can pass some alerts whenever we are
4:29:15sensing any risk out of them, but they
4:29:18are like inevitable. Whenever a hardware
4:29:21fails, it mostly fails abruptly. That's
4:29:24why we use multiple systems in databases
4:29:27as well, and in terms of servers as
4:29:29well, so that if any server crashes or
4:29:31any databases goes down,
4:29:34we can use our system by using the other
4:29:36database or other server, maybe. So,
4:29:38this is what the hardware issue is. Now,
4:29:42let's talk about the second category of
4:29:44our issues, which is software issue.
4:29:47Now, our software issue can be caused
4:29:48through anything. Maybe the code which
4:29:51we are working on is written badly.
4:29:53Maybe we have forgot to handle any
4:29:56exception or anything. Maybe while
4:29:58testing our application, we tested all
4:30:00of the cases, but there are some edge
4:30:01cases which comes to our picture when
4:30:03the user actually uses the application.
4:30:06So, there can be some edge cases. Also,
4:30:09while coding in microservices or using
4:30:11APIs, we also configure them into our
4:30:13configurations. Maybe there can be some
4:30:16issue with the configuration itself that
4:30:18our system stops responding or maybe not
4:30:21responding in a way which it should be
4:30:23responding. Other than that, we can have
4:30:25some deployment issues as well. There
4:30:27can be some issues with the development
4:30:28environment and the production
4:30:30environment mismatch. So, something is
4:30:32working on production but not working on
4:30:34our development or vice versa. These
4:30:36things come on a day-to-day basis in the
4:30:38life of software developers. So, don't
4:30:40worry about this but we have to take
4:30:41care of this and this is our software
4:30:44issue or software fault we can say. With
4:30:46this, if I have to write any other
4:30:48thing, uh one of the major pain points
4:30:50can be merge requests. So, let's say two
4:30:53developers working on similar feature or
4:30:55same file parallelly and when the code
4:30:58compiles of both of them, we need to
4:31:00thoroughly test both of the
4:31:02functionalities so that it doesn't break
4:31:04down each other on the production or on
4:31:06staging or on any environment. So, this
4:31:08is one of the most pain point thing of
4:31:11any developer. Other than that, our
4:31:12software fault or software issue can be,
4:31:15let's say, our requests are taking too
4:31:17much time. So, the performance is also
4:31:20something which software should take
4:31:22care of. But the good and the bad thing
4:31:24about software issues is that it is not
4:31:27random. There has to be something in the
4:31:29configuration or code file which we can
4:31:31find out and solve that issue. Also,
4:31:34this is not random, this is a good thing
4:31:37so that we can find out the issue. But
4:31:39with not random, it is also
4:31:40deterministic which means by following
4:31:43the same steps, we can get that proper
4:31:46error again and again. And if that error
4:31:49is not fixed sooner, that can basically
4:31:51break our system or give a bad
4:31:53experience to our users.
4:31:55So, we need to fix software issues very
4:31:58carefully and ASAP. Now, the third fault
4:32:01is not really a fault but it comes into
4:32:04the category of fault and is considered
4:32:06the most important faults in our system
4:32:09which is human fault. We know that every
4:32:12human is unpredictable and we don't have
4:32:15any control over ourselves. We can do
4:32:17basically anything. So, this kind of
4:32:19issue or error can cause unpredictably.
4:32:23Why? Because humans are considered to be
4:32:26most unreliable components of software
4:32:28development among all.
4:32:30Every component, whenever they are
4:32:32failing or not working, give us an alert
4:32:35beforehand. But with humans, it is
4:32:38sometimes possible, sometimes not
4:32:39possible based on the value of that
4:32:41particular developer or anyone attached
4:32:43to the software development cycle. But
4:32:45with saying these all things about
4:32:47developers or humans, we also need to
4:32:49know that it is one of the most powerful
4:32:52component or person in the software
4:32:55development life cycle. If human stops
4:32:57working, nothing is going to work. Even
4:33:00if the code is written by AI agents or
4:33:03AI anything, Claude, OpenAI, or any
4:33:05other open source, it is still needs to
4:33:08be rectified by human only. Because we
4:33:11need some accountability over that code
4:33:13because that code is going to build a
4:33:15product which is going to be used by
4:33:17humans only. So, we need human in
4:33:20between all these processes. So, this is
4:33:22one of the most powerful thing. That
4:33:24means that makes us responsible for
4:33:27handling the code even more. So, these
4:33:29are the three categories in which we
4:33:30divide our faults normally into. The
4:33:33software issue, the hardware issue, and
4:33:36the human fault or human error. Human
4:33:39issues can be solved by having good
4:33:41behavior or not doing the band-aid fixes
4:33:43or quick fixes in the wrong manner, but
4:33:46going deep into the system and fixing
4:33:48the thing entirely for each and every
4:33:50area. Also, by software issues, we
4:33:53should not write bad code, handle
4:33:55exceptions properly, see the edge cases,
4:33:57maybe do testing thoroughly of each and
4:33:59every component every time you make a
4:34:01build. It can be solved, right? Also,
4:34:04deployment issues can be solved if you
4:34:05configure each and every environment
4:34:07variable carefully. There can be other
4:34:09configurations for databases or for
4:34:11other APIs which can be configured on
4:34:14development environment as well in order
4:34:16to replicate that issue and eventually
4:34:18solve it. Now, if we talk about
4:34:20hardwares, hardwares are something which
4:34:21we don't have any control on. So, if any
4:34:24hardware is going down, it is mostly
4:34:27unpredictable. So, this is also a danger
4:34:29point. That's why we have to scale our
4:34:31system in order to handle the system
4:34:34perfectly or in a better manner. So,
4:34:37this is all about faults and errors.
4:34:39Now, let's understand about the last
4:34:41topic of system design, which is most
4:34:44important but many playlists skip this
4:34:46one. This is our monitoring and
4:34:49observability. We all know that in our
4:34:52product life cycle, our product is once
4:34:54developed will be deployed to any of
4:34:56these servers and then will be
4:34:58maintained. Now, creating a product is
4:35:01entirely different from maintaining that
4:35:04product. Here, we don't have to maybe
4:35:06change a lot of code and add lot of
4:35:08features, but we have to keep monitoring
4:35:11whether our product is working fine or
4:35:14not. So, we have to take care of these
4:35:16following things. Are there any errors
4:35:18in our system or not? Is every component
4:35:20basically is working fine or not? How's
4:35:22the health of each and every server,
4:35:24every component, every database? If
4:35:27there are coming edge cases or any
4:35:29errors in our system, are we recording
4:35:31them correctly? Do we have logs in place
4:35:34so that each and every customer request
4:35:36can be tracked and can be seen whether
4:35:38they are working fine or not. And if
4:35:40there is any error, can we like go to
4:35:42the RCA of that particular error so that
4:35:45our developer can debug and perform the
4:35:47required operation. And also, if any
4:35:49other component is going down or
4:35:51basically down at this particular
4:35:53moment, do we have other systems in
4:35:55place who will take care of the system?
4:35:57And also, do we have proper alert
4:35:59systems so that we can rectify or get
4:36:01these messages beforehand so that we can
4:36:04take care of the situation in a better
4:36:05way. So we need to take care of all of
4:36:07these things plus more in the
4:36:09maintenance phase or while maintaining
4:36:11our application. For example, let's talk
4:36:13about microservices. So one microservice
4:36:17can do two operations, right? Either it
4:36:19can handle a request and work on it or
4:36:22the other thing it can do is it can even
4:36:24redirect the request to any other
4:36:26microservices. So in this case, we have
4:36:28to monitor two things. The first thing
4:36:30is how our APIs are performing and while
4:36:34handling any request or whenever a
4:36:36microservice or a server is working on
4:36:38anything, we need to also check
4:36:40how it is affecting our machine. Like
4:36:43how much memory it is consuming, what
4:36:45are the consequences of this particular
4:36:47request if it gets overloaded or
4:36:49something. So we have to take care of
4:36:51the machine as well as the APIs at the
4:36:54same time. Now let's talk about both of
4:36:56them one by one. So if we talk about API
4:36:59monitoring, the first thing we need to
4:37:01check is our throughput. Now what is
4:37:03throughput? Throughput basically means
4:37:05how many requests can our server handle.
4:37:08Let's say our server can handle 10k
4:37:11requests per second. So that means if
4:37:15our server is already hitting 9k or
4:37:18maybe 8k responses, we have to configure
4:37:21some alerts in order to know whether we
4:37:23are going to hit our throughput or not
4:37:25and maybe we'll migrate the data or the
4:37:27request to some other servers at the
4:37:29particular time because we need this
4:37:31server to perform or to be alive. The
4:37:34other thing which we can monitor while
4:37:35using the APIs can be our error codes.
4:37:39Like we all know about 500 issues and
4:37:43400 issues and maybe we are using some
4:37:45redirects also so 300 issues as well. We
4:37:49need to know how many 500s are we
4:37:51getting, how many 400 requests are we
4:37:53getting, how many 300 requests are we
4:37:55getting. So the first thing is when we
4:37:57are getting too many error things, we
4:37:59need to know the RCA of it. So, that
4:38:02means our logging should be in places so
4:38:05that our developer can work. One thing
4:38:06is that. Also, we need to put some alert
4:38:09whenever the count increases after a
4:38:11particular point so that we can get to
4:38:13know about the 500 issues or 400 issues
4:38:16or 300 issues and fix them accordingly.
4:38:18Third thing is our health check. So, in
4:38:21order to check health of any components,
4:38:24we have already seen that we can do it
4:38:25by two ways, passive and active. So, we
4:38:28have to constantly monitor the 200
4:38:31responses as well and see if our
4:38:33component is in a working condition or
4:38:36not and is giving the positive replies
4:38:38or not. The fourth thing is to check our
4:38:41latency. Latency is a very good metrics
4:38:44in order to check the performance of any
4:38:45system. How can we check the latency?
4:38:48Suppose we have some 10 requests and
4:38:51suppose these values are the response
4:38:53time of those APIs. Now, we need to know
4:38:57the response time of our particular
4:38:59server, of our particular API system.
4:39:02So, how do we calculate them? If we use,
4:39:05let's say, average, the average gives
4:39:07the wrong value because, let's say, our
4:39:09average value for this will come to 6.8
4:39:12seconds, right? But, if we see most of
4:39:15our requests are being handled in a much
4:39:18lower rate. So, this average value
4:39:20basically gives a wrong impression of
4:39:22our services. So, apart from average, we
4:39:26check P values. What is P? P basically
4:39:29stands for percentile. So, what is a
4:39:31percentile? Percentile basically says if
4:39:34we are writing P90, we are saying that
4:39:37our 90% of the request can be handled in
4:39:41a particular seconds or maybe
4:39:44milliseconds, whatever the time is. In
4:39:46our current example, if we arrange them
4:39:48in an ascending order, something like
4:39:50this, we can see that we have 10
4:39:52requests and P90 will be calculated here
4:39:55and all of the requests like 90% of the
4:39:58requests will take lesser time than this
4:40:00time. So, this is our 12 seconds maybe.
4:40:03So, let me also remove this milliseconds
4:40:05for a bit. 12 seconds should not be idle
4:40:07time for any API response. This is just
4:40:09for the example, okay? Similarly, if we
4:40:12talk about let's say P50 here, P50 will
4:40:15be 4 seconds, right? So, that means 50%
4:40:18of our request are currently covered
4:40:21under 4 seconds. So, we can see that P50
4:40:24is 4 second and somehow P90 is 12
4:40:27second, that means something should be
4:40:29off between these two. We have to check
4:40:31all the APIs which are giving us the
4:40:33response of near 12 seconds. And we have
4:40:36to basically optimize them and improve
4:40:38the performance of our entire system.
4:40:40Again, these P90, P50, P70, P maybe
4:40:4699.9,
4:40:47when we have a large system and a lot of
4:40:49calls, so all these matrices and values
4:40:52percentiles help us in jot down how our
4:40:55system is working in a majority portion.
4:40:58And also, we can optimize the
4:41:00performance of our system by checking
4:41:02the differences of different P values.
4:41:04So, it is very useful in case of
4:41:06optimizing our code as well and also, we
4:41:08need to know how our system is
4:41:10eventually working. So, this is what
4:41:13percentile is used for and we use it to
4:41:16calculate the latency of our project.
4:41:18Again, here also, we can provide some
4:41:20alert system. Let's say our P90 here is
4:41:2312 second and if our responses are
4:41:26taking 50 second or something, we should
4:41:28get an additional alert because this is
4:41:31an unusual behavior for us now. So, this
4:41:34is how we take care of latency of our
4:41:36system as well. So, after APIs, let's
4:41:38talk about machine monitoring. By
4:41:40machine, I mean hardware, right? The
4:41:42factors of measuring how our hardwares
4:41:45are working, the first factor if we talk
4:41:47about it can be our CPU usage, like how
4:41:50much power is being consumed by that
4:41:52particular operation or that particular
4:41:55hardware while doing some particular
4:41:56operation. And if that usage basically
4:41:59exceeds any limit, let's say I'm taking
4:42:01example of 75, maybe you can take 70, 90
4:42:04accordingly. We should get an alert that
4:42:07your CPU usage is already attained a
4:42:1075%. So you need to take care of the
4:42:12systems. Again, the other thing can be
4:42:15memory usage. Let's say already we have
4:42:17consumed 90% of the memory.
4:42:20So we know now that our database will
4:42:23not be able to hold more values. So we
4:42:25need to immediately either scale our
4:42:27system or we need to see whether we are
4:42:30getting some error or not. Similarly, we
4:42:32have a lot of input-output operations as
4:42:35well. So we have to take care of disk IO
4:42:37operations as well as network also. In
4:42:40both of these cases, we can set the
4:42:42limit and once the limit is exceed, we
4:42:45can send alerts accordingly. So this is
4:42:47all about monitoring our APIs and
4:42:49machine. Now, let me give you a quick
4:42:51recap of all the things which we have
4:42:53discussed so far. We have discussed
4:42:55about system design, what is system
4:42:57design, what are the different
4:42:59components of system design. Then we
4:43:01have discussed about data intensive and
4:43:03compute intensive applications, then
4:43:05functionality and non-functionality
4:43:07requirements, what is DNS, APIs. We have
4:43:10also understood REST APIs in details.
4:43:13After that we move on to DB, our SQL and
4:43:16no SQL DB with detail. Also, cache and
4:43:19their strategies of eviction as well as
4:43:22how do we store the data in cache. We
4:43:24have completed all the cache part very
4:43:25extensively so that we don't get any
4:43:28issues afterwards.
4:43:29We have also covered load balancing and
4:43:31load balancer in which we have talked
4:43:33about how a load balancer acts as a
4:43:35mediator between the coming request and
4:43:38the request which goes to server. Also,
4:43:41it works as an orchestration between
4:43:43different servers and take care of each
4:43:45and everyone's health. With that, we
4:43:47have covered various forms of
4:43:48replication, partitioning. Ultimately,
4:43:51one of the most important theorems which
4:43:53we're going to cover in each and every
4:43:55interview, that is CAP theorem. Whether
4:43:58you'll choose availability over
4:44:00consistency or vice versa. After CAP
4:44:03theorem, we have covered message queues,
4:44:05fault tolerance, and then we had a brief
4:44:07discussion about monitoring and
4:44:09observability also.
4:44:11So, with all these topics, now we are
4:44:13ready to give any interview or to design
4:44:17any system design component which we
4:44:19want to. We have a solid foundation now.
4:44:22Now, we can design any system. So,
4:44:25congratulations, you have unlocked a new
4:44:27trick, a new component, a new system in
4:44:30your resume, in your abilities. Also, if
4:44:33you feel like I have missed any point or
4:44:35any topic, please mention that in the
4:44:37comment. I may make a video of it in the
4:44:40coming days.
4:44:41With this, let's move to the last part
4:44:43of our video, which is designing a
4:44:46system. So, whenever you appear in an
4:44:48interview of system design or maybe you
4:44:50will design a system by yourself, it is
4:44:52very important to think out loud. So,
4:44:55you have to take your decisions very
4:44:57specifically. No one is looking for the
4:44:59perfect solution, but everyone here is
4:45:01looking for what are the trade-offs you
4:45:03make, what are the components you use.
4:45:05Also, when I'm talking about components,
4:45:08whenever you are using a component, it
4:45:10is very important that you use it for
4:45:12the right reasons. Just because you know
4:45:15about all the components, it is not
4:45:16recommended to add all the components
4:45:18into your system. Because remember,
4:45:21every component you add will add the
4:45:23costing of your system also. So, we have
4:45:26to use the component and design the
4:45:28system very efficiently so that it can
4:45:31be cost-efficient as well as work
4:45:33efficiently to solve our purpose. So,
4:45:36for now, let's design a video streaming
4:45:39application.
4:45:40So, see, we already have a lot of
4:45:42applications. We have YouTube for
4:45:44streaming. We also have, let's say,
4:45:46Hotstar, Netflix, Prime. Also, if we
4:45:50talk about streaming applications, we
4:45:52can also say G Meet is also a streaming
4:45:55application because we can do the live
4:45:57streaming.
4:45:58Uh we can call it a Zoom call or a G
4:46:00Meet also. So, Zoom can also come into
4:46:03this category where we stream our video
4:46:05live to other members. So, a call is
4:46:09basically also an example of a streaming
4:46:10application. Now, with this, we can also
4:46:13use LMS or any other software for
4:46:16streaming our data. We can have more
4:46:18applications. I'm just jotting this down
4:46:20so that you get the idea of the
4:46:22applications which use streaming. Now,
4:46:24before starting, it is very important to
4:46:27jot down the requirement. So, for our
4:46:29video, we doesn't care about user login.
4:46:32We don't care about their reviews and
4:46:35maybe rating also. We don't care about
4:46:38any other operation, but we only need to
4:46:41know how a video basically process from
4:46:44one system to finally our client system.
4:46:48This is what we need to know in this
4:46:50particular example. Now, whenever you
4:46:53appear on an interview also, it is very
4:46:55important to jot down the requirement
4:46:57because let's say they give you an
4:46:59example of designing any software like
4:47:01Netflix, you need to know what are the
4:47:04features the interviewer is interested
4:47:06in. With that, while creating your
4:47:09systems also, you need to know
4:47:10specifically what you are designing
4:47:12because you may be designing an entire
4:47:14LMS, but for that moment, you need to
4:47:17pick feature by feature and design each
4:47:20component and at the end, maybe collect
4:47:22all the findings and create a system.
4:47:25This is how every system is built. Now,
4:47:28here, we only are talking about this
4:47:30process
4:47:31of getting a video to our client system
4:47:34from any server or from any other
4:47:36source. Okay, so let's start from very
4:47:38basic.
4:47:39What is a video? A video is nothing but
4:47:42a collection of different images we can
4:47:45say and with this we also have some
4:47:47audio here.
4:47:48So different images are combined with
4:47:50audio to create a video, okay? So in
4:47:53order to calculate different images we
4:47:55can see FPS or frame per second. We can
4:47:58have 30 or 60.
4:48:00These two things are available. Also, we
4:48:02can use 120 or 240 if they're available.
4:48:05I'm not that sure about it. But yeah,
4:48:07these two frame rates are quite common
4:48:10in our day-to-day life.
4:48:11So what does it mean to have 30 and 60
4:48:14FPS? Basically, in 1 second, if we are
4:48:18using 30 FPS, our video will be divided
4:48:21into 30 images.
4:48:23And if we are using 60, for 1 second, it
4:48:26will be divided into 60 images.
4:48:28So that means the size of 60 FPS will be
4:48:31more than that of a 30 FPS video. But if
4:48:35we talk about the video smoothness, also
4:48:38the 60 FPS video will be more smoother
4:48:41than a 30 FPS video. Now with this,
4:48:44let's stick to 30 FPS thing. Let's say a
4:48:47size of a normal video, let I'm like I
4:48:51am recording a video in 30 FPS right
4:48:53now.
4:48:54My recording, let's say went for 1 hour
4:48:57and for the 1 hour recording video, the
4:48:59size of my recording is basically
4:49:02around 2GB.
4:49:04So if, let's say you are watching this
4:49:06video and if you want to download the
4:49:09entire video in the start before playing
4:49:12and then you play,
4:49:14what will happen? It will add latency to
4:49:17our system because downloading 2GB will
4:49:19take time for sure. Also, you have to
4:49:22see buffer and let's say you downloaded
4:49:25all the 2GBs of content into your system
4:49:27just to see a particular section or
4:49:29maybe you see the first 10 seconds of
4:49:31the video and didn't like it. So, you
4:49:33wasted your internet and storage. So,
4:49:35this is not a good option to download
4:49:372GB entirely first hand and then see a
4:49:40video. It is completely waste of time.
4:49:42So, we have to think about something
4:49:44else. So, the thing is here we have to
4:49:46use some network which is suitable for
4:49:48our system. So, in order to process
4:49:51information in video or images form, we
4:49:53normally go for TCP. Because TCP
4:49:56maintains a sequence of things. Why do
4:49:59we need sequence? Let's see in a bit.
4:50:01So, in TCP we have two protocols. One is
4:50:05RTMP which is Real Time Messaging
4:50:07Protocol and the other one is RTSP which
4:50:09is Real Time Streaming Protocols. Both
4:50:12of these protocols basically help us in
4:50:14order to stream a particular video to
4:50:16our device. Now, what this protocol does
4:50:18is let's say we have a complete video
4:50:20here. It is going to divide our video
4:50:23into different chunks called as
4:50:26segments. And our client machine or the
4:50:28server from which we are watching is
4:50:31going to pull these segments one by one.
4:50:34Now, in message queues we have talked
4:50:35about pull and push. This time I'm
4:50:37saying pull. So, just connect the dots.
4:50:40Keep connecting the dots while I'm
4:50:41saying things, okay? So, this is going
4:50:43to pull our segments one by one based on
4:50:46the network. Now, we'll come to this
4:50:48part in a bit. So, this will solve our
4:50:50issues.
4:50:51This will give us a low latency because
4:50:54we don't have to download the entire
4:50:55video. We can download some segments
4:50:57also. With this we'll now be able to
4:50:59stream in a much better way and it will
4:51:02be more efficient than downloading the
4:51:04entire video which was consuming our
4:51:06resources and network bandwidth. Now,
4:51:08this time we have to only download some
4:51:10segments which is going to be more
4:51:13efficient because this time we are
4:51:15downloading in parts. So, suppose we are
4:51:18watching one video, first 10 seconds is
4:51:20over and now we don't want to watch the
4:51:22entire video. So maybe some or the other
4:51:25sections will be pre-downloaded for us
4:51:27so that if you go ahead we don't see
4:51:30buffer, but we don't have to download
4:51:32the entire video which will save us a
4:51:34lot of space and lot of network
4:51:36bandwidth as well. Now with FPS we also
4:51:39have one more factor which changed the
4:51:41game entirely which is resolution. With
4:51:45videos we have different resolutions,
4:51:47right? We can use 4K, we can use HD, we
4:51:50can use maybe 720p,
4:51:53we can use 480 or 240 or even 144p. Even
4:51:5964p was an option. I'm not sure whether
4:52:02our video will be able to render in that
4:52:04quality or not. I have like way before
4:52:06when I was in school, maybe I saw that.
4:52:09After that I didn't. So yeah, these are
4:52:11all the resolutions on which we can see
4:52:14our video. 4K will obviously have better
4:52:17quality and 144p
4:52:20is going to have bad quality. But why
4:52:23are we talking about resolutions is even
4:52:25if let's say we are streaming a 4K
4:52:28video,
4:52:29which I already said for 1 hour video we
4:52:32need to store it in 2GB space. Suppose
4:52:36we divide this into multiple segments
4:52:38for each second, then 1 second will be
4:52:410.57
4:52:42MB. Now this looks small but is a huge
4:52:45size if we talk about network. What if
4:52:47we have a poor network? What if we are
4:52:50traveling? So our network is keep on
4:52:52fluctuating on a different level. Also
4:52:54if we sit by working on our office or on
4:52:56system, our networks keep on fluctuating
4:52:59as well. So that means we are not going
4:53:02to have a common bandwidth throughout
4:53:04our video viewing experience. So our
4:53:06network will keep on increasing and
4:53:08decreasing. So we have to take care of
4:53:10that also. Let's say I record videos in
4:53:13HD only and if I start recording in 4K,
4:53:17that means the size of 2GB can become
4:53:21big, right? The 2GB can go to 4GB. Maybe
4:53:24I use multi-cam setups. At that time,
4:53:27the 4GB can also go up to 8GB, maybe.
4:53:30Also, in my videos, I'm not doing much
4:53:32activity. The frames are pretty still.
4:53:35Only my hand movements can be shown once
4:53:37in a while. I'm sitting still. I'm just
4:53:39facing the camera or the screen. I'm not
4:53:41doing much activities. Also, the screen
4:53:43you are seeing is black on which I'm
4:53:45writing in white. So, there are no
4:53:47colors, also. So, this is pretty easy
4:53:50video to see. But, if I start recording
4:53:53outside or maybe I start recording any
4:53:55action sequence, so in that case, the
4:53:57size can also get to 16GB for the same
4:54:014K video of 1 hour. So, this size can
4:54:04also be increased to four times. So,
4:54:06that will be around 4MB. So, the issue
4:54:09here is for even 1-second video, we are
4:54:12using 4MB. And if our network is not
4:54:15that good, we are still going to see
4:54:17buffer or face loading issues, which is
4:54:20going to basically ruin the experience
4:54:22of our viewer, and they will leave the
4:54:24application. This is not what we want
4:54:27entirely, right? So, we have to do
4:54:28something about it. Also, if you think
4:54:30about it, there are different screens on
4:54:32which you work on. We maybe watching
4:54:34something on TV. We maybe using our
4:54:36laptop screen. Uh also, we can use our
4:54:39mobile screen, maybe our watch as well.
4:54:42Maybe we are seeing it on iPad. We don't
4:54:44want 4K qualities in all of them, right?
4:54:47Let's say we are watching on watch, we
4:54:49don't want 4K.
4:54:51Maybe on watch, 480 works fine. And
4:54:54also, on iPad, also, I don't think 4K is
4:54:57required. Maybe we can show them in SD,
4:54:59and it will be enough. On TV, we
4:55:01basically require 4K. Like, we don't
4:55:03have to compromise here. But, on laptop,
4:55:06also, we can switch between HD and 4K.
4:55:09We can choose. We can pick based on the
4:55:11requirement or based on the
4:55:12configuration, based on the network
4:55:14also. On mobile also, we can work pretty
4:55:17well with SD. We don't need 4K here as
4:55:19well. So, that means not only network,
4:55:22but based on our screen size, we can
4:55:24change the resolution of our video. So,
4:55:26why are we changing?
4:55:28Because it is going to reduce the size
4:55:30of our segment. And the lesser the size,
4:55:32the faster it will be to show. So, in
4:55:34order to maintain streaming, we have one
4:55:37mechanisms, which is adaptive bitrate
4:55:39streaming. What it basically conveys is,
4:55:42let's say you start watching a video on
4:55:44300 Mbps. And your networks keep on
4:55:47fluctuating. Maybe it went down till 10
4:55:50Mbps. So, when the network fluctuates,
4:55:52we can't download with the same
4:55:54consistency. And if we are not able to
4:55:56download with the same consistency,
4:55:58there's high chance of seeing the buffer
4:56:01icon. And we don't want that.
4:56:03So, in order to achieve this, what can
4:56:05we do? We have a source video
4:56:08of 4K, right?
4:56:10We have to divide this video into
4:56:12different segments, that we know. Also,
4:56:15we have to divide those segments into
4:56:17different qualities. So, for example,
4:56:20this 4K video is divided into 10
4:56:22segments of 4K quality. But now, also we
4:56:25have to divide these segments into more
4:56:27configurations, the lower
4:56:29configurations. Now, our basic
4:56:31resolutions and segments are ready. Now,
4:56:34let's see in real time how our function
4:56:37really works. So, let's say here we have
4:56:39our client who is watching something on
4:56:42our desktop screen. In starting, the
4:56:44network connection was 300 Mbps. So, we
4:56:48start showing them the 4K video. So, it
4:56:51sees segment one, maybe segment two also
4:56:53he watches. And then, the network drops
4:56:56to 10 Mbps. So, at this point, maybe
4:56:59this is already loaded into their system
4:57:02in the form of cache. So, they can still
4:57:04see this section into 4K. But after
4:57:06that, we need to load the data again.
4:57:09And the network is now at 10 Mbps. So,
4:57:12we can't load the 4K data. What we will
4:57:14do, we will load the lower configuration
4:57:17data. Maybe according to this we will
4:57:19pick 480p.
4:57:22So, we will start downloading this data.
4:57:24And once the network restores to maybe
4:57:26300 or 150 Mbps, we will start switching
4:57:30our configurations accordingly. So, we
4:57:32can go to 1080p as well. And if it then
4:57:37drops to 50 Mbps, we can still give them
4:57:40720p. And at the end, if network
4:57:43basically restores to 300 Mbps,
4:57:47we can show them the last segment in 4K
4:57:49again. So, this is how an YouTube or any
4:57:52other stream basically works.
4:57:55They will keep switching our quality
4:57:57based on our network bandwidth because
4:57:59we are mostly seeing that entire video
4:58:01on a single screen.
4:58:03And based on our network, they will keep
4:58:05switching the qualities. And we see the
4:58:07entire video into one go
4:58:10without seeing the much difference there
4:58:12because normally the network doesn't
4:58:14drop so drastically. We just keep these
4:58:16segments in order to show them into
4:58:18different devices. If you pay attention
4:58:21in most of the streaming applications
4:58:23where you are seeing the video, in the
4:58:25side corner, you also see a segment
4:58:27where you can switch your configurations
4:58:29again. You can choose between auto,
4:58:33maybe HD, or maybe they will directly
4:58:36use the configuration that is 720p or
4:58:39480p,
4:58:40something like this.
4:58:42So, you can choose between them. And if
4:58:44you choose auto,
4:58:46they are going to perform this
4:58:47orchestration or this game while you
4:58:49watch the entire video. So, what did we
4:58:52see here? If the network throughput,
4:58:55that means our network speed, is greater
4:58:57than the bitrate of the downloaded
4:59:00segment, that means we have downloaded
4:59:02in a lower quality and now network is
4:59:05greater than that. So we can now switch
4:59:09to a better quality. Similarly, if the
4:59:12network throughput is less than
4:59:15the bitrate of
4:59:17downloaded segment, so in this case what
4:59:21we will do, we will switch down the
4:59:23quality of our video. So after getting
4:59:26all this knowledge, after discussing all
4:59:28these things with your interviewer or
4:59:30with your team,
4:59:31then you start deciding what components
4:59:33do you use in your system design. Now
4:59:36the path is very clear, right? We need
4:59:38to store the current data or the actual
4:59:41data somewhere. Maybe this is our CDN
4:59:44where the actual data or the actual
4:59:46video is uploaded and it is uploaded
4:59:48from where? From any server. Now from
4:59:51here we need to create the segments, so
4:59:53that means we need to give this data to
4:59:55a service which can basically transform
4:59:58our video. So we can name that we can
5:00:00say it is a transformation service. Now
5:00:03after this we have to send the segments
5:00:06to our queue. We can use priority queue
5:00:08here, right? So we can create a queue.
5:00:11And why we are using priority queue? You
5:00:13need to answer yourself. Now
5:00:15from this message queue, our system is
5:00:18going to use the services of downgrading
5:00:21each and every quality. So we use worker
5:00:24term here. Worker is basically used in
5:00:26order to denote another service. So we
5:00:29may be using worker one for downgrading
5:00:32it to HD. Also we can use worker two for
5:00:35maybe downgrading it to 720p and so
5:00:39forth. So after working with these
5:00:41resolutions, again we need a message
5:00:43queue to store the results into segments
5:00:46and again we need a priority queue here.
5:00:48Okay, with this we will send this
5:00:50request to a distributed CDN kind of
5:00:52services from where it can go into
5:00:55different part of our servers. So, if
5:00:58someone is watching from India, they can
5:01:00access the data from this server and
5:01:03they can watch it from US server and the
5:01:05other servers are for other regions.
5:01:07Now, by doing this, we have completed
5:01:10the entire system design of our video
5:01:12streaming application. And from this
5:01:14server,
5:01:15eventually, we are going to access it on
5:01:17our client machine on which our user is
5:01:20going to watch their video. So, now
5:01:22after creating this diagram, let's also
5:01:24do some maths.
5:01:26Let's say our source video is of 50 GB
5:01:30and it is of 20 minutes. So, it is a
5:01:33high-quality video, maybe 4K, and it is
5:01:35having 60 FPS. So, that's why the size
5:01:38is too big. So, this is we are taking as
5:01:40an average size of the video which we
5:01:42are going to stream. Maybe we are
5:01:44streaming an entire match. So, this is
5:01:46the size which we are going for our
5:01:4720-minute video. Now, let's decide how
5:01:50many segments can we divide it to. So,
5:01:52I'm doing an easy maths. So, 20 minutes
5:01:55multiplied by
5:01:5760, that will convert it into seconds.
5:02:00So, it will be 1 2 0 0 seconds. And
5:02:04also, I am making the segments also
5:02:06equal, so that means 1 2 0 0
5:02:09segments as well. Also, with this, let's
5:02:11talk about different resolutions. So,
5:02:13let's say 4K is of 50 GB, which will be
5:02:17divided by our segment. So, here the
5:02:19size of our segment is too large, right?
5:02:21Because it is a 4K video. Maybe we can
5:02:24divide it into more segments. So, but
5:02:27for this example, let's stick to it.
5:02:29Let's say our 1080 pixel video,
5:02:32let it be for 20 GB and again, we are
5:02:35going to divide it by 1200. It is going
5:02:38to be again 16.6 MB.
5:02:41With this, let me write all the
5:02:42resolutions.
5:02:43Now, this is what the calculation looks
5:02:45like if we divide it for each segment
5:02:47for each resolution. For 720, it will be
5:02:508.3 MB. For 480, it will be 4.17. And
5:02:54for 250, it will be 2.08 MB. That means
5:02:57if we combine them all, it is going to
5:03:00be 72.65
5:03:02MB, approximately. So, that means the
5:03:05size of one segment of our video is
5:03:08going to be 72 MB, which is too huge, I
5:03:11feel. So, maybe we can divide it into
5:03:13further segments. But for now, this is
5:03:15going to be the size of our one segment.
5:03:18And accordingly, we need to load the
5:03:20data into our stream.
5:03:22Also, while calculating the size, we
5:03:24should also take care of our user. That
5:03:26means we should know how many users are
5:03:29going to see the stream. So, if the user
5:03:31count is, let's say, 100, we can use the
5:03:34same server or a single server only,
5:03:36right? For 100 number. If we count this,
5:03:39it will comes down to 87.5 GB.
5:03:42So, we can store 87.5
5:03:44GB
5:03:46into a single server, and from which
5:03:48these 100 users can view our streaming
5:03:51easily. What if the user changes from
5:03:54100 users to 100,000 users? Now, this
5:03:58will change our picture. Now, this is
5:04:00where we will know that our one server
5:04:03is maybe not enough to cater so much
5:04:05requests. So, we will divide our servers
5:04:08into two, maybe. And based on the number
5:04:11of users, we have to keep increasing the
5:04:13count of servers. Maybe we'll use
5:04:15message queues. Maybe we'll add some
5:04:17caching algorithms. And all of this will
5:04:19be managed through our diagram. Here, I
5:04:22have not used any caching. But we can
5:04:25use the caching on CDN level.
5:04:28Or we can use the cache on our browser
5:04:30level,
5:04:31which is going to hold the segments of
5:04:33the coming part. So, this is what the
5:04:35design look like. This is what the
5:04:37calculation is. And this is what is the
5:04:39logic behind the system design of my
5:04:42system, which will stream our video to a
5:04:4610,000 or a 100,000 user. Now, this
5:04:49diagram can be different in your case
5:04:52also. It is very possible that you will
5:04:54design a system better than me, and it
5:04:57is also possible that you will see some
5:04:59other YouTube video who have designed
5:05:01the video better than me or maybe worse
5:05:03than me. So, these designs are basically
5:05:06your practice.
5:05:08The more you practice, the more you see
5:05:10other designs, the more you read
5:05:12different papers, your designs are going
5:05:14to improve. And more your design
5:05:16improves, the quality of your system or
5:05:18your workflow increases with time. So,
5:05:21with this, I end the discussion of
5:05:23system design.
5:05:24And I really hope you all enjoyed this
5:05:26series so far. This was a long video,
5:05:29and we covered a lot of topic. I hope
5:05:31you all enjoyed it. Now, you can like
5:05:34this video or comment the most
5:05:35interesting section you found out in
5:05:37this video. Also, you can comment out
5:05:40any topic which you want to see in
5:05:42future on Telescop. With this, my name
5:05:45is Akshat Agarwal, signing off. Thank
5:05:47you.

About this transcript

This page contains the full transcript of System Design One Shot Full Course by Telusko, generated from the public captions YouTube serves with the video. The transcript has 52,361 words across 7,560 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to choose a caption track available on the video.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, caption language selection, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.