What Happens When You Type google.com In Browser ? | System Design

Añadido: 2026-05-23

[00:00:00]Every single day, we open website like Google, YouTube, Instagram, Amazon.

[00:00:06]Right? You simply type youtube.com or google.com, then you press enter. Then, website appears within a milliseconds.

[00:00:15]But, have you ever wondered what actually happen after you pressing the enter button?

[00:00:20]How does browser know where Google or YouTube server exist?

[00:00:24]How does request travel through internet?

[00:00:27]And most interesting part, how does all this happens within fraction of seconds?

[00:00:33]So, well, in this video, we'll understand the complete journey of a request step by step. Okay? All right.

[00:00:41]And trust me, this is one of the commonly asked system design interview question. So, without any further delay, let's get started.

[00:00:51]>> [music] >> So, let's say you open your Chrome browser and type youtube.com/javatechy.

[00:01:07]Next, the moment you press enter button, the browser will first understand the URL.

[00:01:14]So, this is your URL to access the javatechy YouTube channel. As part of this particular URL, it contains multiple section. Okay? So, the first one, HTTP or HTTP, this is called protocol.

[00:01:29]So, let me add here, this is called protocol.

[00:01:34]And the second section, www.youtube.com, that is nothing called domain.

[00:01:40]Okay? Domain to access YouTube.

[00:01:44]Now, /javatechy, that is called path.

[00:01:49]This is the resource you want to access.

[00:01:53]Now, here is the interesting part.

[00:01:55]We have typed here youtube.com, which is a domain name. As a human, we use domain name like google.com, youtube.com, or facebook.com to access any website because they are easy to remember. But, computers don't communicate using domain name.

[00:02:15]They communicate using IP address. For example, let's say this is where my YouTube server up and running. This is the IP of YouTube server. Okay?

[00:02:26]Similarly, we have other domain like google.com, amazon.com, facebook.com, any.com, or.org. Every website has their own IP address. So, this is what something IP assigned to every domain.

[00:02:42]Now, imagine if as a human I had to remember IP address for every website instead of typing google.com, I would have to type this particular IP address.

[00:02:54]And for every single website, there is different numbers. There is different combinations. So, internet would become a nightmare to use, isn't it? So, before talking to YouTube, the browser first need the IP address of YouTube server.

[00:03:09]Now, you can see the IP address of YouTube server is something like this.

[00:03:13]142.250.183.206.

[00:03:16]But, this browser don't know about the IP of YouTube. Now, that is the reason DNS come into the picture. Okay? So, there is another component called DNS.

[00:03:31]And this DNS stands for domain name system. Okay? This is one components. Everywhere it is being used to face the IP address by taking the domain name. So, this particular system is called domain name system, or in short you can call it as a DNS. You can think of it like the internet phonebook.

[00:03:54]Just like we can't remember all our friends or relatives phone number, right? That is the reason we use contact application and we keep number something like this. I have Rahul who is my friend because he's my friend and I keep the phone number like this.

[00:04:10]Okay? Similar way, this DNS also store domain and IP mapping. youtube.com map to this particular IP address, google.com map to this particular IP address. Similarly, Amazon and Facebook also has different IP mapping. This DNS store all those information.

[00:04:31]So, this process of finding IP address based on the domain name is called DNS resolution or even you can call it as a DNS lookup. So, I hope till this point we all are at the same page.

[00:04:46]But, wait.

[00:04:47]Does the browser contact DNS server in every single time? Now, let's say I type google.com, then immediately browser will go and check in the DNS?

[00:04:56]Does browser will do this DNS lookup or DNS DNS resolution fetching the IP by domain name?

[00:05:02]No, that would be very slow.

[00:05:04]So, what browser does? Browser first check, do I already know this IP address?

[00:05:11]Because maybe you open youtube.com few minutes ago.

[00:05:15]Okay? So, for that reason, what browser does? It start checking the cache one by one. Okay? There are different type of cache. What browser does? He first start checking in the browser cache so that he will figure out, okay, user tried this domain few seconds or few minutes before. Let me get the IP from cache.

[00:05:36]If IP not found in this browser cache, then what it does? It go and check the OS cache. If IP found in OS cache, well and good. If not, it will and check in the DNS cache. Okay? So, if DNS cache also has the information of IP address, well and good. Otherwise, browser will go and do the DNS resolution from this domain name system. Okay? So, let me arrange it properly so that it will be easy to visualize.

[00:06:06]So, I believe this make more sense. So, what browser will do? First, it will check in each and every cache. Browser cache, then OS cache, then DNS cache.

[00:06:17]If it found anywhere in the cache, DNS lookup is skipped completely.

[00:06:23]If it is not found, if not found, then it will start the DNS lookup journey.

[00:06:32]Now, what happened? As part of DNS lookup, there is something called recursive resolver flow.

[00:06:40]It's not that browser will directly go to the DNS and DNS have this direct information and give it back to the browser. No, there is a process called recursive resolver flow. Now, what happened in this recursive resolver flow? Browser first ask to the different DNS server, "Hey, you have this IP? Give it to me." If that guy don't have the IP address, he will forward to the next DNS server. Like that, there is a sequence of execution to get the IP address. So, let me highlight all those DNS server.

[00:07:15]Now, these are the different DNS server.

[00:07:18]DNS server will not directly give you the IP address based on the domain name.

[00:07:23]There is a process called recursive resolver. Okay? So, this process is called DNS.

[00:07:32]Fine. I mean, if you are more into the networking, you'll get clear picture of it since we are discussing this from the dev perspective, I'll not go in-depth about each and every DNS server, okay?

[00:07:44]Let me place it in the correct flow.

[00:07:48]Now, what your browser does, he'll not directly forward request to the DNS server, rather he'll do the DNS recursive resolver. Now, what happened?

[00:07:58]The request will first goes to this root DNS server.

[00:08:04]Browser ask, "Hey, where can I find.com domains?"

[00:08:08]Then this root DNS what it does, it will simply reply, "Ask the.com LTD DNS."

[00:08:15]Okay? Like we have.com,.org, based on that, it will forward to the.com DNS.

[00:08:22]Now, again, resolver ask this DNS recursive resolver ask to the.com DNS, "Hey, can you tell me where can I find youtube.com IP address?"

[00:08:33]Then this.com server replies, "Ask YouTube DNS server." Okay? Every website has their own uh DNS server, okay? Like Google also has its own Google DNS server.

[00:08:48]Similarly, Facebook also has its own Facebook uh DNS server. Like that, that is the last DNS server option. Root DNS will delegate to.com DNS..com don't know where is the YouTube server exist, so it will simply forward to the YouTube authoritative DNS.

[00:09:06]Okay? Now, this particular YouTube DNS server will give the IP. What is the IP?

[00:09:11]142.250.183.206.

[00:09:16]This guy will return the real IP address.

[00:09:20]After executing this DNS recursive resolver, you get the final IP address from the last YouTube own DNS server.

[00:09:30]Okay? This whole process of keep looping and fetching the IP address based on the domain name is called DNS recursive resolver.

[00:09:39]Now, since you get the IP address, I mean your browser get the IP address, simply what you will do, you'll replace this youtube.com with the IP address.

[00:09:49]Okay?

[00:09:50]Since this is the IP address of YouTube server, which you want to access, and you get this IP address through this DNS recursive resolver, now your browser will replace this youtube.com domain to IP and try to access your YouTube server.

[00:10:07]Now, here is the interesting part.

[00:10:09]Still, your browser cannot directly send the data. Okay? I have the IP. I know where is YouTube server is up and running, but still I cannot directly send request to this YouTube server.

[00:10:22]Because YouTube use HTTPS, which is a secured protocol. First, it needs to establish a TCP connection, and also it need TLS handshake. Okay? This step create a secure encrypted connection between your browser and YouTube server.

[00:10:41]Only after this secure connection is established, then your browser can send the actual HTTP request to this particular YouTube server. So, what is the step it will do?

[00:10:53]It will maintain the uh or it will do the TCP connection.

[00:10:58]Then, it will have the TLS handshake.

[00:11:01]Okay, I mean the uh encrypted key exchange.

[00:11:04]Once that connection is established successfully, then only what happened?

[00:11:09]Your browser can build a request packet.

[00:11:13]When I'm saying request packet, what is the URL you want to access? What is the HTTP methods, headers, cookies, authentication info? All those needs to be passed as part of the request packet.

[00:11:26]Now, let me create a request packet.

[00:11:28]So, this is how your request packet will looks like. I believe everyone might have seen this when you inspect in browser. Every request has this information.

[00:11:38]Whether you access Google, YouTube, or any website, you'll find these things as part of your developer tools when you will do the inspect. You can check what is the payload or what is the parameter we are sending as part of the request packet.

[00:11:51]Okay? So, to make it more meaningful, I'll remove this.

[00:11:55]You understand this this required the TCP connection and TLS handshake.

[00:12:00]Then, this is how once that is done, it will build this particular request packet.

[00:12:09]Now, the moment once you press enter with this particular request, what happened? First, this request will not directly goes to this YouTube server.

[00:12:19]Rather, you're connecting in the private network, right? You have your Wi-Fi router, all those stuff.

[00:12:25]So, first, it will go to your home Wi-Fi or office Wi-Fi, wherever you are using.

[00:12:31]Okay? It will go to Wi-Fi router.

[00:12:35]Your request will goes to Wi-Fi router.

[00:12:39]Once request went to this Wi-Fi router, now what happened? Wi-Fi router will forward that request to internet service provider.

[00:12:49]Something like this. Okay?

[00:12:52]You can name it internet service provider.

[00:12:57]Router will delegate that request to internet service provider. When I'm saying internet service provider, it depends which internet you are using. It could be Jio, Airtel, ACT, BSNL, any any Wi-Fi you are using. Okay? That particular network is nothing your service provider. Basically, it depends mostly the network you are using.

[00:13:21]So, now this internet service provider becomes your gateway to the internet.

[00:13:27]Now, it starts one of the coolest part that is called internet routing. See, there are so many magic happening behind the scene.

[00:13:36]Now, once request reach to the service provider internet service provider, it will not directly forward that request to YouTube server.

[00:13:45]To make things more flexible, to make things more faster, it internally use some concept called internet routing.

[00:13:54]Now, what happen in this internet routing, let me tell you.

[00:13:57]Let's say this is internet routing. And you have multiple router. Let's say router one. It's not your personal router. It is the router available across the globe.

[00:14:12]Router two.

[00:14:14]Router three.

[00:14:17]Router N. There are so many routers.

[00:14:22]So, now what happen? This internet service provider forward your request to router, which is present across the world.

[00:14:31]Now, every router look at this particular request packet and decide which path is fastest to reach this YouTube server. It is same like how Google Map suggest you the best or fastest route, right? Same way, different routers dynamically decide the fastest and most efficient path to reach Google or YouTube server. The request can landed to router three or router two or router N. Okay? Which will make your request flow faster to reach to the YouTube data center.

[00:15:09]Now, eventually the request reaches the YouTube infrastructure. After this internet routing, your request reach to YouTube server.

[00:15:20]Now, you might be thinking, okay, after so many struggling, request finally reached to the YouTube server and I can able to access it, right?" But even here, the request usually does not directly hit the application server.

[00:15:34]Because first, it may pass through CDN edge server, load balancer, reverse proxies. This system help Google or YouTube handle billion of request efficiently. Don't worry, we'll discuss each of them in upcoming videos. But for now, I just want you to hear these words. Okay? Then finally, what happened? YouTube backend server got your request. Here, let's say it got the request. Then it will process the response. Okay? Now, how it will process the response? Let me add a path of our response flow.

[00:16:10]So, once YouTube server generate the response, while the reverse flow to return response to the browser, it does one interesting part that is called rendering. Okay? As part of rendering, what YouTube server will return? Since you have just typed {slash} Java Techie, what it does, it will give you the HTML, CSS, Java JavaScript, images, and few API data. So, that user can visualize the page. Okay? Along with that, as part of the response flow, there could be some static content like images, videos, or JavaScript file, or CSS content.

[00:16:51]Those things will not directly get from your YouTube server. Okay?

[00:16:56]For that reason, there is a another component called CDN. That particular component called CDN. CDN stands for content delivery network.

[00:17:08]Okay? This is what called CDN. So, few static content like images, videos, JavaScript, or this JS, all those are static content may come from nearby CDN server instead of getting those information from original server. Okay?

[00:17:27]Do you know why?

[00:17:29]Because downloading from nearby location is much faster.

[00:17:33]Always you will not go to the Dmart to purchase your groceries, right?

[00:17:37]Sometimes if you need one or two item, you can go to your nearby store which is near to your home. Similar way when we are rendering the response for static content, we no need to hit the original server.

[00:17:50]We can get it from nearby CDN. Okay?

[00:17:54]Content delivery network. It could be placed in different region. It could be in South Central, it could be in US, it could be in India. There are different content delivery network will available across the globe. So from there, we can fetch the static information so that it will be the response will be much faster. That's why when you open the YouTube, it loads quickly even when millions of people are online.

[00:18:20]Correct? Now response starts traveling back to your browser.

[00:18:24]Your browser will show you the content of whatever the URL you have typed. Okay?

[00:18:31]If you type google.com, IP will be replaced and all the flow will happen and then you will see the home page of Google. Since I'm trying here {slash} javatechy, I'll see the javatechy YouTube channel, all the recent content and how the uh template looks of YouTube, you'll get the exact view.

[00:18:48]Isn't it interesting?

[00:18:50]All of these DNS lookup, TLS handshake, internet routing, backend processing, CDN delivery, rendering the content, all these happens within a millisecond.

[00:19:01]And that is what actually happen when you type youtube.com in your browser.

[00:19:07]I hope now you have a clear understanding of what happen behind the scene.

[00:19:12]So, you can picture as this particular image. If you want I can show you the better view of this particular flow.

[00:19:20]This is the complete architecture of request flow begin from browser.

[00:19:26]When you type google.com it go and check the browser cache, OS cache, DNS cache. If it found well and good if it will skip the DNS lookup and continue. If it doesn't found then it start the DNS resolution process which is nothing DNS resolution flow.

[00:19:45]Recursively resolve with DNS then it will check in each and every DNS server and finally the own DNS server will return you the IP address then your browser will build the request and it will send to the Wi-Fi routers then Wi-Fi router will forward it to the internet service provider then the coolest part of figuring out which router make my request process much faster. It does the internet routing.

[00:20:10]So, there are so many router across the globe. Okay? Which one is close to the YouTube data center or Google data center based on that it will filter out the routes. Okay? Then finally your request will reach to the Google data center and your response travel back to the browser.

[00:20:30]While returning the response it will return I mean your browser rendering as part of the response flow it does these many things. It will pass the HTML, apply the CSS, execute the JavaScript, finally it render the page. But before that if there is any static content it will fetch from nearby CDN content delivery network. Okay? And finally you'll see the home page of the URL you have typed.

[00:20:55]This particular flow has so many components or so many basics to understand. Okay? That is the reason this is one of the most popular system design interview question.

[00:21:06]So, well if you enjoyed this video and learned something new, make sure to like, subscribe, and share it with your friend.

[00:21:13]And in the next video, we'll dive into client-server architecture and other important system design concept. Also, guys, I just want to do a small call out. I know many of you are loving this system design series and asking for more frequent videos. Honestly, system design is very vast topic and along with YouTube, I'm also managing my regular office work. So, sometimes it become difficult for me to upload videos very frequently. I can't promise, but I will definitely try to upload at least two videos in every week. I'll definitely give it a try for that. Okay? So, thank you so much for all your support. I'll see you in the next video.