What Happens When the UI Calls the Backend?

You've seen the diagram. Boxes labelled "nginx," "load balancer," "reverse proxy," "service mesh," arrows everywhere, and a feeling that real engineers were born understanding it. They weren't. That diagram wasn't designed in one go; it grew, one box at a time, and every box was added to solve a specific, understandable problem.

So we'll grow it ourselves. We start with the smallest possible system, push it until it breaks, and add exactly one piece to fix each break. By the end, the scary diagram will just look like a list of sensible decisions. No prior backend knowledge needed.

First, what even is "calling the backend"?

Your UI runs in a browser on someone's phone. The backend is a program running on a computer somewhere else (a "server"). When your UI does fetch('https://api.shop.com/products'), here's the plain-English version of what happens:

1. Find the address

   api.shop.com is a name, like "the pizza place." The browser asks DNS (the internet's phone book) "what's the actual number for this name?" and gets back an IP address, like 93.184.216.34.

2. Knock on the door

   The browser opens a connection to that address on a specific port (a numbered door on the machine; web traffic usually uses port 443 for HTTPS).

3. Send the request

   Over that connection it sends an HTTP request: "GET /products, please." Just text, really.

4. Get the response

   The backend program reads the request, does its work, and sends back an HTTP response: a status code (200 = OK) and some data (your products as JSON).

That's it. A "call to the backend" is your code sending a little text message to a program on another computer and getting a text message back. Everything else in this article is about what's on the other side of that connection, and how it grows.

System 1: one cook, one stall

The simplest backend is a single program listening on a port. In Node, the whole thing fits on screen:

import { createServer } from 'node:http';

const server = createServer((req, res) => {
  if (req.url === '/products') {
    res.writeHead(200, { 'content-type': 'application/json' });
    res.end(JSON.stringify([{ id: 1, name: 'Keyboard' }]));
  } else {
    res.writeHead(404);
    res.end('Not found');
  }
});

server.listen(3000); // listening on port 3000

System 2: the cook needs a pantry (the database)

Our cook is keeping the menu in their head. But real data (users, orders, products) can't live "in the program's memory" — if the program restarts, it's all gone, and a second copy of the program wouldn't share it. The data needs a permanent home: a database.

The server doesn't store the data itself anymore. It asks the database for it.

// The server now reads from a database instead of hardcoded data
const products = await db.query('SELECT id, name FROM products');
res.end(JSON.stringify(products.rows));

The "connection" and why we pool them

Talking to a database means opening a connection to it (just like the browser opened a connection to the server). But opening a fresh connection is slow and the database can only handle a limited number at once. So the server keeps a small set of connections open and reuses them. That set is a connection pool.

// Don't open a new connection per request — reuse a small pool.
const pool = new Pool({ max: 20 }); // keep up to 20 ready
const result = await pool.query('SELECT * FROM products WHERE id = $1', [id]);

System 3: one cook can't keep up (load balancer)

The stall got popular. One server program can only handle so many requests at once before everyone waits. The fix isn't a magic faster cook; it's more cooks: run several copies of the exact same server program (on more machines, or more containers).

But now there's a new question. The browser knows one address. Which copy of the server should handle each request? Something has to stand in front and hand out requests. That's a load balancer.

How does it pick? Two common strategies, and you can feel them in code. Run this:

Round robin just takes turns. Least connections sends the next request to the least-busy server. The load balancer also does health checks: it quietly pings each server, and if one stops answering, it's taken out of rotation so no requests get sent into the void.

System 4: a proper front desk (reverse proxy / nginx)

We have several servers behind a load balancer. But a few jobs don't belong inside your app code, and you don't want to do them in every server copy:

• Handling HTTPS/TLS (the encryption padlock) so your app code deals in plain HTTP internally.
• Serving static files (images, the built JavaScript) without bothering the app.
• Routing by URL: send /api/* to the app servers, /images/* to a file store.
• Hiding the messy internals behind one clean public address.

The thing that sits at the very front and does this is a reverse proxy, and the most famous one is nginx. (A load balancer is often built into the reverse proxy — nginx can do both, which is why these boxes blur together in real diagrams.)

# A tiny nginx reverse-proxy config
server {
  listen 443 ssl;                       # handle HTTPS here
  server_name api.shop.com;

  location /images/ {
    root /var/www;                      # serve files directly
  }

  location /api/ {
    proxy_pass http://app_servers;      # forward everything else to the app
  }
}

upstream app_servers {                  # the pool it load-balances across
  server 10.0.0.1:3000;
  server 10.0.0.2:3000;
}

Wait — "proxy," "reverse proxy," what's the difference?

The word proxy just means "something that acts on behalf of someone else." The direction is the whole distinction:

Same idea (a middleman), opposite sides. A forward proxy hides the clients from the internet; a reverse proxy hides the servers from the internet. In backend architecture you'll almost always mean the reverse kind.

System 5: the kitchen gets stations (microservices)

So far, all our app servers run one program that does everything: products, orders, payments, emails, search. That single do-everything program is called a monolith, and for most teams it's the right choice for a long time.

But imagine the app gets huge and so does the team. Everyone edits the same codebase and trips over each other. The payment code and the search code have totally different needs, but they're stuck deploying together. At some point you might split the one big program into several smaller ones, each owning one job and talking to the others over the network. Those are microservices.

The whole journey, end to end

Now put every layer together and follow a single tap of "Buy" through the grown-up system. None of it is mysterious anymore, because you watched each box arrive.

Want to go deeper on any single box? The full-stack track walks through the runtime, databases, and APIs, and the system design deep dives show these layers handling real scale, like 60 million people watching one cricket match.