System Design

What happens when we enter www.google.com?

How a browser reaches a website and how an application begins to scale.

system design

When we enter www.google.com in our browser, we get the Google Search interface.

But what happens behind the scenes?

How does typing www.google.com eventually bring the search engine interface into our browser?

Google has servers that are publicly accessible. To communicate with those servers, the browser needs to know where to send the request.

The first thing that happens is DNS resolution.

When we enter www.google.com, the browser needs to find the IP address associated with that domain name. DNS helps translate the domain name into an IP address.

After resolving the address, the browser can establish a connection with Google’s infrastructure and send a request. The server processes the request and sends a response back to the browser.

To communicate between the browser and the server, we commonly use HTTP (Hypertext Transfer Protocol), or HTTPS in most modern web applications.

Now, let’s think about a simple application.

At the beginning, we might have one server and one database running on a single machine. This can work well when the traffic is low.

But what happens when the traffic starts increasing?

One server might eventually become unable to handle all incoming requests. There are two main approaches we can take:

  • Increase the resources of the existing server.
  • Add more servers and distribute the traffic between them.

These approaches are called vertical scaling and horizontal scaling.

Vertical scaling means increasing the resources of an existing machine, such as CPU or memory. However, there is a limit how much we can scale the machine.

Horizontal scaling means adding more machines to handle the workload.

For example, instead of running everything on a single machine, we can separate the application server and the database. Then we can run multiple application server instances.

But now we have another problem.

If we have multiple servers, how do we decide which server should handle an incoming request?

This is where a load balancer comes in.

Instead of clients directly sending requests to individual application servers, incoming traffic first reaches the load balancer. The load balancer then distributes requests among the available servers.

Because of this, the application servers do not necessarily need to be directly exposed to the public internet. The load balancer acts as the public entry point and forwards traffic to the appropriate servers.

Now we can scale our application servers horizontally.

But there is still another question.

What happens when the database becomes the bottleneck? How do we scale the database when database traffic starts increasing?

That is the next thing I want to learn and write about.