System Design 101: Design for Beginners

1. 01 Intro: I worked at FAC, taken countless system design interviews, and one thing is clear. The difference between an average candidate and a great one is how solid their fundamentals are. They may not have designed that exact system before that I've asked in the question, but their core understanding allows them to improvise and build confidently on top of the fundamentals. Now that is my exact goal in this video. I will try to break down all these fundamental building blocks, those buzzwords, technical jargons that sound complex, but they really now, once you get these fundamentals, these terms will feel simpler and almost obvious to you. My goal is to impart a field of these concepts to you so that you can get in love with these concepts, you can remember them easily, and you can ultimately realize that System Design isn't just about memorizing. It's about understanding. I hope you enjoy this and once these fundamentals click, trust me, you'll already be ahead of B. 2. 02 IP Address: We are going to talk about something that's absolutely essential for computers to communicate on the Internet, all as the IP addresses. Now, just as every person in this world is known by their need. Each computer on the Internet is known by its IP address. Take a look at this diagram. Here's what an IP address Michael Klein, 172, that two, 17, 22, 14. It's kind of like say Hello, there. I am 172.217 0.22 0.14. This is the way computers introduce themselves to each other on the Internet. But sometimes an IP address might look even more complicated, something like this. Well, that's a very horrible name. It's no wonder we use domain names like sweetcy.com instead of remembering these long string of numbers. IP address come in different formats like IPV four, which looks like the first example or IPV six, which looks like the second exam. A key point is that every device connected to the Internet has a unique IP address, ensuring that the data knows where exactly to if it like sending a letter. If you don't have the correct address, the letter won't reach the person you're trying to contact. Similarly, if you don't have the correct IP address, the data won't reach the right computer. IP address are foundation of how the Internet works, making sure billions of devices can communicate with each other without getting lost. 3. 03 Dns: DNS or domain name system. Let's say when you type sweequory.com in your browser. What happens next? The browser needs to connect to Sweet Codey servers to load the homepage. But it first has to figure out where that server is located. This is where the DNS comes in. Here's how it works. Your browser asks, where is sweetqoy.com? This question is sent to the DNS server. The DNS server checks its records and responds. It's at ten dot two dot 312. Now your browser knows the exact IP address of the Sweet Codey server. Finally, your browser uses this IP address to connect directly to Sweet Codey servers and the home page loads on your screen. The DNS is just like a phone book. When you enter a website name like sweetcoy.com, the DNS takes that name and looks up the corresponding IP address of the server. Without DNS, you'd have to remember the IP addresses of every website you want to visit. That would be covers. Imagine having to recall something like ten dot two dot three or 12 instead of just typing suetquery.com. Definitely not fun. Thankfully, TNS handles all that for you, translating easy to remember names into the precise IP addresses that computers use to communicate. 4. 04 Cloud Computing: Many people think that the cloud is some magical place where your data floats are. Here's the truth. There is no such thing as the cloud. All the cloud computing happens in physical servers located in some data centers. What is cloud computing all about? Let's break it down with the help of a simple example. Imagine you want to create a website like sweetcody.com. Now to host your website, you definitely need servers that would host your website data, that would host your business logic. Now here's the challenge. You can buy the physical servers yourself and then maintain it and develop it. But buying and maintaining the physical servers is expensive and time consuming. You'd have to purchase the hardware, maintain the servers, take care of their security, backups, power supply, and then replace them when they break down. This is where cloud computing comes in to save the day. Instead of buying and maintaining the servers yourself, how about this that you rent them from famous companies like Amazon, Google, or Microsoft? These companies have huge data senders full of the servers that are ready to use for you. So how does it work? Let's say you're trying to host sweetcy.com. The user visits sweetqory.com on their device. The client sends a request to the server that is now hosted in the Cloud, which might be either WS, which might be Azure, which might be Google Cloud. The server then fetches your data from the data store, and finally, the server sends the web page back to the user's device. All this part that is highlighted here is actually rented from the famous Cloud providers. By the way, a fun fact. Did you know that EWS, which is the famous Cloud provider service by Amazon started as an experiment? Amazon originally built EWS just to handle their own retail business. But then they realized, hey, we could rent out this infrastructure to others, today, EWS is the biggest Cloud provider in the world. Not talking about what are the benefits of cloud computing versus actually physically purchasing your servers and maintaining it. First is Scalability. When we use the cloud, it lets you increase or decrease your server capacity instantly. All of this is managed by these big companies. You don't need to buy new servers when your website gets more visitors. It would be a simple configuration change and all these things would be handled by these famous companies. Second, this is super cost effective. Why is this the case? Because you only pay for the server resources you actually use. If perhaps during the holidays, your graphics shoots down, can actually decrease your server resources would be, again, a simple configuration change. This is in contrast where you actually own the physical servers, and then you have to shut them down and whatnot. This would make it cheaper than maintaining the physical servers for sure. Third is reliability. Now using the servers from the Cloud is super reliable option because all these big companies would handle the maintenance, security, and backups for you. Definitely, these big giants can handle these aspects much better than you yourself or your small individual company. Cloud computing has transformed how the websites and apps are posted. Instead of worrying about the hardware, you can actually focus on building your business, while Cloud providers like ADR Lewis Azure GCP they would take care of all the infrastructure. 5. 05 Client & Server: Let's dive into the relationship between client and server. Two key players in how the Internet works. First, let's break it down. What is a client? A client is a computer or a device that requests for the information. It could be a laptop, smartphone, or even a smart a server. Server is a computer that provides or serves the requested information to the client. Servers store the data and resources that client requests. To make this more concrete, let's look at some everyday examples. Imagine you're sitting on your couch and your smart TV is streaming movies from Netflix. Scenario, your smart TV is the client requesting for the movie information. Of course, we have the Netflix servers that is giving those information back to the client. Or think about when you're using your phone to get directions on the Google Maps. Here, your phone is the client requesting location data from the Google Maps servers. Take a look at this diagram. The left, we have the user and their laptop. This represents the client. The client is saying, show me the website homepage, which is a request for the information. On the right, we have the server that is the machine that hosts the website. The server responds back by saying, here is your request at homepage so that the client can then display on the screen. Without servers, clients wouldn't have anywhere to get the information they need. Without clients, servers wouldn't have anyone to serve. It's a symbiotic relationship that powers the entire Internet. 6. 06 Protocols: Just as humans use grammatical rules to communicate, computers also follow certain rules while communicating. These rules are nothing but the protocols. Based on what the task is, you might use different rules or the protocols for it. For example, if the task is to do some common web interactions like sending or receiving web pages or perhaps updating the content on the summer, we use SGTP protocol. Similarly, if the task is to transfer files, we use the FTP protocol, AK the Phi transparent protocol. 7. 07 TCP: Let's look at some popular protocols. We'll start with TCP, also called as the Transmission Control Protocol. Imagine you are streaming a movie and after the first scene, you suddenly see the climax, totally confusing. Well, TCP makes sure that doesn't happen. It's a protocol that ensures son data packets are delivered in the current sequence, so you watch the movie in the proper order. Take a look at this diagram. The client on the left, ask the server if the server can give the Harry Potter movie. Server sends the data packets, or you might think of them as movie scenes back to the client. Now, TCP ensures that these scenes are in the right order without jumbling in. 8. 08 UDP: Let's now talk about UDP, the user datagram protocol. Imagine you're watching a live football key. There is emphasis on the word live. You want the action to feel as real time as possible with no delay. If that means missing a few seconds of footage here and there. UDP is perfect for this. It sends the video very quickly, but it doesn't guarantee that every single piece of the data will arrive, unlike TCP, which focuses on delivering every part of the data in order. UDP is all about speed. It sends data super fast, even if it skips a bit here and there. This makes it breed for live events where being up to the second is more important than perfect accuracy. Take a look at the diagram. The client, your device, requests to watch a live football game from the server. UDP start sending the video stream as quickly as possible. See how the red arrow is labeled super fast. That's UDP getting the video to you quickly. But sometimes you might miss the four to 6 seconds of footage. That's okay. It's because with live events, you care more about being in the moment than seeing every single frame perfectly. Now why sometimes during live streaming, you might miss a small part of the action when the game skips for a few seconds, it's all because UDP is working to keep things fast and as lively as possible. 9. 09 HTTP: IPod text transferred protocol, the most commonly used protocol on the Internet. STDB is just a back and forth conversation. You, the client, ask for something, and the server responds. For example, when you click on a product while shopping online, your browser sends a request to the server, which then sends back the product details. In the diagram, you can see that the client is refuesting for a web page from the server. The server fetches the data and sends the web page back to the client, making it visible on your screen. 10. 10 Websockets: In the traditional protocols like SGDP, the communication is one directional. What do we mean by one direction? It means that the client sends a request and then the server responds back. But with Websockets, the communication is bidirectional. This means both the client and the server can send data to each other anytime. For instance, think about a live chat application instead of constantly asking the server, do you have new message? Do you have new message? Websockets allows the server itself to push messages directly to the client. Soon as they arrive. This makes the communication much more efficient and real time. In the diagram, you can see how both the client and the server can send data back and forth freely, maintaining a continuous two way conversation. 11. 11 Forward Proxy: You can think of Forward Proxy as your own personal assistant. I'll give you an example. In the image, you can see that you are the client and your assistant is the Forward Proxy. Let's say you need to have vegetables. What do you do? You ask your assistant to get the vegetables from the market for you. He will head out, grab the wedging and bring them back similarly in the Internet world, when your computer, Ak, the client, when it needs something from outside or from the Internet, it would just ask the Forward Proxy to fetch it. The Forward Proxy goes to the Internet, gets the required data and brings it back to your computer. 12. 12 Reverse Proxy: Now let's try to understand reverse proxy. Understanding Reverse Proxy is very similar to understanding forward proxy. But with an exception that this time you can imagine the Reverse Proxy to be a personal assistant, but for your family, not yourself. What does it mean? Let's saying an example. Assume that the external world is trying to contact your family. In this case, all these requests doesn't have to go directly through our family, but instead, it would go through your assistant. The assistant would first decide which requests or which calls are important. I would perhaps filter the non important on the unnecessary calls. Eventually, you put forward only the appropriate or the right calls to the corresponding family member. Similarly, the reverse proxy in the digital world sits between the Internet and the savors. By the Internet, you can imagine the outside world. A servers, it's your family, and here is the Reverse Proxy, which is the assistant for your family or the savors. So how does it work? Whenever there is a request from the Internet, the Reverse Proxy would first receive it. It would filter the non important or the unnecessary requests. Ultimately, it would forward the important requests to the appropriate servers. 13. 13 API: But what exactly is an API? Just like people are social. The computers are social, they like to talk to each other but with the help of EPS. An API or the application programming interface is simply a way for the computers to talk to each other. Now, just like people can communicate to each other in numerous ways. It might be using symbols, using words or maybe gestures. Similarly, computers can also communicate with each other in different ways. We'll discuss the three most popular ways using wrist, Craft Quin and GRPC. 14. 14 Rest API: Begin with an analogy. Suppose you go to a restaurant. You take a look at the menu, you browse various options, and then you decide, perhaps you want burger and fries. You then please your order with the water. Who notes it down, releas it to the kitchen, and then ultimately brings your meal back to you. Just like a restaurant has a menu that lists the specific dishes that you can order. Computers use rest EPS to communicate only in certain standardized ways. Now, these standardized ways are just like the items on the menu. That is, they define the specific type of requests that you can make here are the four most common type of standardized operations used in Grass API, SGTPG Here you ask the server for data, SGDPPost. Here, you add the data to the server, SGTP batch. Here, you update an existing data on the server, SGTP delete. Here, you remove the data from the server. 15. 15 GraphQL: Let's continue our restaurant and luncheon. But this time, instead of just choosing from the menu, you decide to customize your meat, you want perhaps a burger with extra pickles, extra cheese, and a dutene free ball. The waiter takes note of your custom order, communicates it to the chef, and then the chef prepares your meal exactly as you requested. The waiter then brings you the meal, Taner precisely to your taste and how you gave the customization request. This is exactly how the graft cure operates in the digital world. Unlike ist, where you have to select predefined options like choosing items from a fixed menu. In draft Qb, it lets you to customize your request. That is, you can ask for exactly what you need all in a single quake. In ist, you'd have to please separate orders for each items, perhaps one for the burger, one for extra pickles, another for extra cheese, and yet another for the KutenFreePu. Then you would assemble everything yourself. But if graft, you, you describe your complete custom order in one request. The server, like the chef understands your Dt request and then delivers exactly what you need in one go. In the diagram, you can see that the client sends a request to the server, asking for a block along with all the related posts, their authors, and their recent cords. This request is fully customized. You're asking for multiple pieces of information in one go, just like ordering a customized burger. 16. 16 GRPC: I'll begin with an analogic. Imagine that you are at a restaurant. You want burger and fries, you tell the waiter about that. Waiter takes that order and then tells the kitchen about that. Now in this process when the waiter communicates with the kitchen staff, he doesn't see the full order. Instead, he quickly tells the kitchen, D plus F for table one. Instead of saying one burger and one fries for the table one. Using this shorthand helps the workers who faster and more efficiently. This quick communication is similar to how the GRPC works in technology. Just like the restaurant staff uses a short code to save time. GRPC allows different parts of the system to talk to each other using something very similar to the short codes. It is called Protocol Buffers or protobus. Ptobfs are like the shorthand that the waiter used. That is, they pack a lot of information into smaller and efficient format. This ensures everything runs faster and with less data. Now let's take a look at the diagram. On the left, we have a user who wants to purchase a course on System Design. The user device sends a request to the server to purchase this course. Service side, Microservices are talking to each other to complete this purchase. The payment processing service processes the payment. The course enrollment service enrolls the user in the course. The user notification service sends a notification to the user confirming a successful purchase. On these micro services communicate with each other using GRPC, allowing them to complete the transaction quickly and efficiently, just like the quick shorthand communication between the waiter and the kitchen staff. 17. 17 Message queue: Let us begin with an example. Imagine a home owner with a long list of tasks, prepare food, take out the trash, clean the house, and wash the dishes. Well, these tasks have to be completed before the homeowner leaves for work. He also has a helper or maid to assist with these tasks. Scenario one, doing one task at a time. Now in this first scenario, the homeowner gives tasks to the maid one by one. The homeowner waits for each task to be completed before assigning the next one. This method is inefficient because it wastes time. The homeowner has to wait for each task to be finished before moving on, delaying his departure for work. Scenario use a checklist. In the second scenario, the homeowner writes down all the tasks on a checklist and then leaves for work. The mate picks these tasks from the checklist and completes them one by one independently. This is much more efficient because the homeowner can leave for work on time while the mate continues to work through the task at our own pace. How this relates to message queues? A Message queue works just like the checklist in the second scenario. The home owner is the producer who adds tasks, also called as messages. He adds these messages to the queue, which is similar to the checklist, and then ultimately the mate who is in the consumer. Processes these tasks from the queue one by one. Benefits of Message queue, efficiency, the homeowner saves time and can focus on other tasks without waiting for each one to be processed. Second, good management. The checklist ensures that no tasks are forgotten or lost. If the maid takes a break or steps out, the task will still be there when she returns and she can pick up right there she Nipto third, reliability. This ensures all the tasks will be completed by the end of the day. Even if the maid takes a break, what are some drawbacks of message cues O complicating simple tasks. For quick tasks like perhaps turning on a light switch or adding sugar to coffee, writing them down on a checklist is unnecessary and slows things down. Second, D for urgent tasks. For urgent tasks like turning off a burning stove, fretting them down and waiting for the maid to see them would be way too slow. Some tasks need immediate action. 18. 18 Scalability: I'll begin with a simple example. Imagine a small cozy bakery in your neighborhood. When the bakery first opened, they just had one cashino and everything ran smoothly. Customers would come in, place their orders, pay at the counter, and then leave satisfied with their delicious pastries. But then slowly, the bakery started gaining more popularity. The line of customers grew longer and the waiting time increased. People began to feel very frustrated. And some even walked out just because they didn't have the time to wait. To tackle this problem, the owner of the bakery decided to open additional checkout counters. Now, instead of one cashier, there were three. This made it much easier to handle the growing grou, reducing the wait times and keeping the customers happy. Effectively, the Baker had scaled up. To meet the increasing demand, just like our bakery. Our technical systems also need to scale up as more and more users join. Scalability in tech is effectively the system's ability to handle more work smoothly as the demand grows. A well designed system can scale up more easily, ensuring that it can serve more users without any performance issues. 19. 19 Availability: Availability means how much time a system is up and running. Think of it like your favorite 247 convenience store. That's always open day or night, whenever you need something. Another example, online banking. When you access the online banking website, that's available 247. It greatly improves your experience. It ensures you can access your account perform transactions anytime of the day. You wouldn't want your bank to be on a break when you need to transfer money urgently. We often express availability in nines. What is nines? Give you an example. When we say a system has 99.999% availability, also known as five nines, it means the system is allowed only 5 minutes of downtime per year, 5 minutes or 0.001%. That's incredibly available. It's like your favorite convenience store just being closed for 5 minutes in one game. 20. 20 Strong Consistency: Consistency means making sure everyone sees the same information at the same time. I'll start with a simple analogy. Imagine a teacher announces that there is a test tomorrow. If the teacher tells all the students at the same time, that's consistency. But if only half of the students hear the announcement and the other half don't know about the test, that's inconsistency. There are two types of consistency, Strong Consistency and eventual consistency. What is a strong consistency? Strong Consistency means that as soon as the information is updated, Everyone sees the same updated information immediately. There is emphasis on the word immediately. That is, there is no delay. 21. 21 Eventual Consistency: Eventual Consistency. Eventual Consistency means that the information will become the same for everyone over time, but not right away. There might be a short delay before everyone sees the updated information. I'll start with an example to explain both of these concepts. Suppose that you have $1,000 in your bank account. You withdraw $200. The bank updates your balance to $800 immediately. Now if you or someone else checks your balance, it shows $800 right away. On the other hand, consider the example for Eventual Consistency. You have $1,000 in your bank account, you withdraw $200. The bank might still show $1,000 for a short time and it is only after some delay like one R, the bank updates the balance to $800. Now, in some situations, strong consistency is crucial. While in others, Eventual Consistency or delayed consistency is acceptable. The example that we were looking, the bank transactions. Strong Consistency is of utmost importance. If the balances don't update immediately, it could lead to errors like withdrawing the same money twice. On the other hand, consider the example of social media posts. Eventual Consistency is fine if you post something on Instagram, it's okay if there's a small before all of your friends see it. As long as everyone eventually sees the post, there's no major harm. A fun fact. Did you know that early banking systems had big problems with consistency? Sometimes people could withdraw the same amount of money more than once just because the balances didn't update quickly. This actually caused huge financial losses. This is why strong consistency is so important in the banking today. 22. 22 SPOF: We're going to talk about another important design goal and that is to ensure that our system does not have a single point of failure. I'll start with a simple analogy. Imagine that you are crossing a bridge. That bridge is supported just by one pillar. Now, if that pillar collapses, the entire bridge falls. That pillar is the single point of failure for the bridge. If it goes down, the whole bridge is unusable. Similar to this, we don't want any single point of failure in our system. Let's use our website example. A user tries to open the website. Client requests the web page. There's a server that handles the user request and it fetches the web page from the data store. Now, what happens if this server goes down? The entire website becomes inaccessible. Here, the server is the single point of failure. If it fails, none of this flow is going to work and everything stops. Now, how can we avoid single point of failure? Naturally by adding more servers, also known as by adding redundancy. This makes our system more tolerant to failures. If one part fails, others can take over ensuring continuous operation. Technically, we say that we have made our system fault tolerant. Some examples of a fault tolerant system. If one server in the data center fails, another server comes to take over and the website remains accessible to users. Perhaps, if the entire data center fails, another data center takes over. The website remains accessible agap because the secondary data center steps in to handle the traffic. 23. 23 SQL: Have you ever worked with tables or spreadsheets? If so, you already have a good idea of how the relational databases work. This is the closest analogy I can give for a relational database. Relational or SQL databases store the data in a table like format. You can think of it like spreadsheets, having rows and columns. Relational databases are perfect for such type of data. What data? Data that has a well structured format that can easily fit into the rows and columns. For example, think about the use of data. It's structured. Why? Because it can be organized into predefined fields like name, email, phone number, and address. Some popular examples of relational database are my SQL and post dress. When I try to think of relational database, I think of it as a well organized library in a library. Each book is categorized and placed in a specific location based on its author, title, publisher, and cost. Now, contrast it with an example of unstructured data. You can imagine your storage room filled with all sorts of random items or junk items. It may be your own box of documents, photos, videos, chairs, tables, et cetera. There is no inherent structure to the stuff you are putting it there. It's all randle. 24. 24 NOSQL: But what happens when our data doesn't fit neatly into predefined categories or it is unstructured? Let's take social media posts as an example. Imagine trying to store these posts in a table with columns for text, images and videos. Now, if the post has only text, the image and the video columns remain empty. Similarly, if the post has a video, the text and the images columns remain empty. This leads to a lot of wasted space in our table, which isn't very efficient. Look at this image. Here, you can see how the table has many empty entries because each post doesn't always have content in every column. This is where inefficiency is coming in. The table is designed for a structured data, but social media posts don't always follow a strict structure. They're more like random items in our storeroom example from earlier, you know, no predefined format. This is where we have the no SQL database. Which is ideal for handling this kind of unstructured data. So instead of forcing everything into a rigid table, no SQL databases allow you to store each post just as it is. Each post can be stored in a flexible format like a JSON document, which can handle different types of data, text, images, text and images, text and videos, you know, anything. Let's take a look at the second diga. Here, you can see how each social media post is stored as a JSON document in a non SQL database. Each post is complete within its own document, and there is no wasted space. Plus, these documents can be easily accessed using a key like a post tidy, for instance, making it quick and efficient to retrieve the data you need. Co fact. Those equal databases aren't just one type. There are various kinds, each designed to handle different types of unstructured data. We have key value stores, document databases like the one we looked, graph databases or sorting relationships, white column databases, and even time series databases on tracking the data over time. Some popular examples of no SQL databases include MGA TV, Cassandra, Panama TV. These databases are designed to be highly scalable and flexible. Perfect for modern applications that deal with a variety of data types, might be unstructured, might be structured, whatever. So just like how a storeroom can handle all sorts of different items without any strict organization. No SQL databases are perfect for handling unstructured and varied data. They give us the flexibility to store and manage data in a way that fits our needs without wasting space or forcing everything into a rigid structure. 25. 25 SQL vs NOSQL: Now that we have explored both the SQL and the no SQL databases, the natural question is, how do you choose between them? So let's dive into some general guidelines that can help you decide. But keep in mind, it's not always black and white. Your choice will often depend on the specific means of your project. First, speed. If you need very fast data access, no SQL databases might be generally preferred overseas. Now SQL databases are designed to handle large volumes of data and can retrieve the information pretty quickly, making them a great choice for real time applications. Next is scale. When the scale is too large, no SQL databases tend to perform better than the SQL databases. No SQL databases are built to scale horizontally, meaning that you can add more database servers to handle more data. This makes them ideal for applications with massive amounts of data like social media platforms or big data applications. But what if your data fits into a fixed structure? This should prompt us to think about SQL databases. If your data is well organized and has a consistent predefined format like the user data which we saw, feels for name, email, phone number, address, et cetera. This kind of data goes very well with the SQL database. Other hand, if your data doesn't fit into a fixed structure, no SQL should be your choice. Remember our laying sample of social media posts, that kind of unstructured data would go well with the no SQL databases. Another consideration is the complexity of your queries. If you have complex queries that needs to be executed on your data, SQL is the pair choice. SQL databases are designed for intricate queries that involve multiple tables, fix joins, and filtering. But if your queries are simpler and more straightforward, no SQL databases can handle them just fine. They are optimized for quick, easy access to the data. Without the need for complex querying or operations. Lastly, let's talk about flexibility. If your data changes frequently or is likely to evolve over time, go for a no SQL database. No SQL databases support a flexible structure, allowing you to add new fields, change the format of your data without much hassle. This is particularly useful for rapidly evolving applications where the data model is in set in stone. In summary, SQL databases, great for structure data, complex queries, and applications where you can expect the data to be inconsistent format. No SQL databases, on the other hand, are perfect for unstructured data, large scale applications and scenarios where flexibility and speed are the key. You got it right. Flexibility and adaptability can take you much further than rigidity. After all, in both databases life, the ability to evolve with the times can be the key to success. Remember, these are just general guidelines, and the best choice often depends on the unique requirements of your project. It's all about finding the right tool for your job. 26. 26 Object Storage: The Internet is full of photos, videos, music, and all kinds of files. But, have you ever wondered where all this stuff is stored? That's where the Object Storage comes. Object Storage is perfect for handling large amounts of data, like these photos, videos, audios that we constantly upload and share. In Object Storage, we simply store the data as objects. Imagine it like a big digital bucket where you can toss in all sorts of these objects, photos, videos, music, documents, et cetera. Popular services that offer Object Storage are Amazon S three, Goble Cloud Storage, and Microsoft Azure Blob Storage. Here's a fun fact. Amazon S three, one of the most popular Object Storage services, is currently storing over 100 trillion objects. So no matter how much digital stuff you have, there is plenty of room in the bucket. 27. 27 CDN: CDN or the content delivery network. I'll start with an example. Let's say Sweet Codey has all its servers in the US, and then a user from India tries to opensweetcory.com. The website assets like images, videos are pretty bulky, and this bulky content has to travel all the way from the US to India. Now, this long journey increases the latency, meaning the user has to wait longer for the website to load. This is where AsciiN comes in. Asdian stores copies of your website's static content. What is a static the content which is static EGA that doesn't change too often. Things like images, videos, and other files. So a Syrian stores copies of such static content at various locations around the world. So when someone from India would say tries to access sweetqoy.com, they get the content from a nearby Syrian server instead of waiting for it to come all the way from the US. Take a look at the diagram. You can see how users in India and the US get the website content from their nearest Sal servers. You know, the users in India are getting it from the Syrian in India. Similarly, the users in US are getting it from the Syrian in US. This cuts down the distance the data has to travel and therefore speeds up the whole process. 28. 28 Cache: Accessing the data directly from the database can take some time. But if we want to speed things up, we use a cache. Think of the cache as a special kind of super fast memory, where we store the frequently accessed data. In fact, accessing the data from a cache is around 50 to hundred times faster than accessing it from the database. It's like keeping snacks close to you at your desk while you're studying. So instead of walking to the kitchen every time you're hungry, which is like going to the database. Simply grab a snack from your disk. Again, similar to using a cache. But just like how you cannot store everything on your disk, a cache has a limited capacity compared to a database. That is where we store only the most frequently used data in the cache. Now, let's look at what happens when you try to get the data from a cache. Let's look at the first diagram. Here, User one is requesting some data. The system first checks the cache. Since user one's data is already in the cache, it is quickly fetched from there. This is called a cache hit. Because the data was found in the cache, so we have hit the cache. But what happens if the data is not in the cache? Let's look at the next diagram. In this case, user four is requesting for the data. User four's data is not in the cache this time. So the system has to go all the way to the database to fetch it, which takes longer. This is called a cache miss. It's a miss because we cannot find the data in the cache, and we had to go to the database to retrieve it. By the way, after the data is retrieved, it is added to the cache so that the next time user four needs it, it can be quickly fished from there. Now in the final diagram, User four requests the data again. Now, this time, since we have already saved user four's data in the cache, we just grab the data from the cache quicker and much faster. Just like grabbing the snacks from your desk. Using a cache is a great way to make your system faster by reducing the number of times you have to go to the database for the same data. You can use the cache at multiple layers. You can use it at the database layer, perhaps at the server layer, perhaps even at the client layer. 29. 29 Cache Aside Strategy: Let us take a look at the Cache Aside Strategy. How does it work? When the data is requested, the server would first check in the cache to see if the data is already available. If the data is not found aka or cache miss, then the server would retrieve this data from the database, then it would store in the cache so that it will be available for any other future requests. Let us take a look at the diagram to understand this bitter. User four makes a request. When the request comes to the server, the first thing that the server does is check if user force data is already in the cache. This is the step one that is highlighted in the diagram. Now since user force data is not present in the cache, that is, this is a cache miss. Now, in this case, the server would fetch this data from the database that is highlighted in the step two. Now after getting the data from the database, the server would then update the cache to include the user force data in the cache. This is because next time there is a request for user for, we can just quickly retrieve it from the cache without going to the database. 30. 30 Read Through Strategy: Now in the read through strategy, a Cache itself would be responsible for fetching the data if it's not already present. So when the server requests the data, the cache will first check in the data is available. If not, the cache itself would fetch that data from the database and save it in the cache for future requests. Now, you can take a look at the diagram to understand this bitter. I Quist comes from user for. The request comes to the server, which would first check the data in the cache for user for data. Now if user force data is not found in the cache, which is the case here, instead of the server fetching the data from the database, this time the cache would fetch the data from the database. After fetching the data, the cache would then update itself with this data for all the future requests so that next time there is a request for user force data, it would be found in the cache. This strategy is called as a read through strategy because effectively the server is reading the data from the database with the help of a cache or it is reading through the cache. So it simplifies the logic at the server site as the cache itself would be handling all the interactions with the database. In both of these strategies, the goal is to minimize expensive database reads by using the cache for frequently requested data. 31. 31 Logging and Monitoring: So logging is just like a computer writing his diary. Just as you write down important events, thoughts or issues in a diary, the server also logs all of its key activities like what requests it is executing, how it is executing, what responses it is giving back to the client, any errors that it faces or any other important notable system events. All of this it logs in its diary. This is what logging is essentially. You can think of logs as footprints left behind. If something goes wrong, developers can go through these logs and figure out what exactly caused the issue, so it put even help in troubleshooting. Now in the first diagram, you can see that the server is writing its tidy whenever it gets a request. It notes down each of these steps so that we have a record of what exactly happened. For example, the client here demands the website homepage in this process. The request is sent to the server, and this is what the server logs then. The client has demanded homepage from me. Perhaps it would log. I need to retrieve the website assets from the Object Storage. Once it has actually retrieved them, perhaps it can log, I have successfully retrieved the website assets from Object Storage. Ultimately, just before sending these website homepage back to the client, it can log, I'm sending the website back to the user. Effectively the server is writing diary and keeping track of what exactly happened throughout this process. Now let's come to the monitoring. Monitoring is just like having a security camera that is watching our server's diary. If something goes wrong, alerts are triggered to notify the developers that, hey, perhaps this has gone wrong and you need to take a look and fix it. Let's take a look at the example. You can see in the diagram that again, the client requests the website homepage. Now, the server starts logging all of these events as we have discussed. Now, if perhaps, let's say there is an error when it tries to retrieve the website assets, which is marked as red in the logs. Then our monitoring system will catch this. Once it has caught this, it would send an alert to the developers. The developers can then take a closer look at our system and then try to fix the shoe. So this monitoring system effectively ensures that we catch the errors or anything that requires urgent attention and then conveys that to the developers so that it can be fixed ASAP. Now, what is the importance of logging and monitoring? Pretty intuitive, right? Logging would help us understand what exactly happened, giving a detailed look when required, and monitoring, on the other hand, would help us send alerts to the developers when something happened that shouldn't happen. Together, these processes would help our systems stay healthy and efficient, making sure that issues are identified and resolved quickly and efficiently before they affect our users.