🌐 What Actually Happens When You Hit "Enter"

I used to think backend development was just getting code to run on localhost. But jumping into system design made me realize it is mostly about answering one question: How do different parts of a system communicate reliably and fast?

If you understand how a single web request works, you understand the foundation of distributed systems. Here is the mental model.

The Core Mental Model

At its core, the web is just a client-server architecture.

  • Client: The one asking for something (your browser, a mobile app).
  • Server: The one providing it (the machine running the backend code).
  • Protocol: The strict set of rules they both agree to use to talk to each other (usually HTTP).

My favourite way to think about this is a restaurant:

  1. You sit down and give your order to the waiter (Client Request).
  2. The kitchen cooks the food (Server Processing).
  3. The waiter brings your food back (Server Response).

As long as you and the waiter speak the same language (Protocol), you get your food.

The Step-by-Step Breakdown

Let's say you type a URL into your browser. It feels instant, but here is the messy, multi-step journey happening under the hood.

1. The Browser breaks down the URL The browser looks at the URL and chops it into pieces so it knows how to connect (the protocol, like HTTPS), who to connect to (the domain), and what exactly to ask for (the path).

2. Finding the actual machine (DNS) This part used to feel like pure magic to me until I actually had to configure the DNS records for my own aparagarwal.tech domain.

Humans like readable names, but computers only understand IP addresses (like 93.184.216.34). Your browser has to ask the Domain Name System (DNS)—which is basically the internet's giant phonebook—"Hey, what is the exact IP address for this domain?"

3. The Handshake Before any actual data is sent, the client and server have to establish a connection. They say hello, agree on how to encrypt the data so nobody else can read it (this is the TLS handshake that makes HTTPS secure), and set up a reliable channel.

4. The Request is Sent Now the browser actually asks for what it wants. It sends an HTTP request that includes a method (like GET for fetching data, or POST for sending data) and some metadata headers.

5. The Server Does the Work This is where our backend code lives. The server receives the request and starts running the business logic. It might check if you are logged in, validate your data, ask the database for information, or check a cache.

6. The Response The server packages up the result and sends it back. This includes a status code (like 200 OK or the dreaded 500 Internal Server Error) and the actual data you asked for, like a JSON payload or HTML files.

7. Painting the Screen Finally, the browser takes that data and turns it into the visual page you actually see.

Seeing it in Action: My URL Shortener

This whole cycle finally clicked for me when I built my own URL shortener. Here is exactly what happens when a user creates a new short link:

  1. The Request: The browser sends a POST request with a long URL.
  2. The Processing: My Node.js backend receives it, checks if the URL is valid, and runs the logic to generate a random short code (like aB12x).
  3. The Database: The server saves that mapping (aB12x → long-url) into the database.
  4. The Response: The server sends back a 201 Created status with the new short URL in JSON format.

Later, when someone clicks that short link:

  1. Their browser sends a GET request for that specific code.
  2. My server looks up the code in the database.
  3. It sends back a redirect response (301 or 302).
  4. The browser automatically follows that redirect to the original long URL.

Building that out was my biggest "Aha!" moment for understanding request-response cycles.

Where I'm Still Figuring Things Out

Understanding this single loop is great, but the "design" part of system design comes in when you have millions of these requests happening at once.

This is where things get fuzzy for me, and what I'll be exploring next in this journal. I know the definitions of things like Load Balancers (distributing requests across multiple servers) and CDNs (putting data physically closer to the user to make it faster), but I still need to build my intuition on exactly when and how to implement them without over-engineering things.

Quick Reality Checks (Things I got wrong at first)

  • The internet is NOT the web. The internet is the physical wires and network infrastructure. The web is just one application running on top of it.
  • One page load is rarely one request. I used to think loading a website was one big transaction. In reality, the initial HTML loads, and then the browser fires off dozens of secondary requests for images, CSS, and API data.