01) What a Backend Actually Is (and Why It Exists at All)

5 min readFeb 1, 2026

For a long time, I had a very surface-level idea of what a backend was.

Something like:

“A server that responds to API requests.”

That definition isn’t wrong — but it’s incomplete in a way that hides almost everything that matters.

So I decided to slow down and trace it properly. Not just the code part, but the physical flow, the infrastructure, and the reason this thing exists in the first place.

This is me documenting that understanding.

So… what is a backend?

In its most traditional sense, a backend is simply a computer.

A computer that:

listens for requests
over HTTP, WebSockets, gRPC, or similar protocols
through an open port (usually 80 or 443)
and is reachable over the internet

Because other machines can connect to it, send data to it, or receive data from it, we call it a server.

And what does it serve?

Sometimes:

static files like HTML, CSS, JavaScript, images

Other times:

structured data, usually JSON

It can also accept data, process it, and store it.

That’s a fair definition.

But it still feels abstract.

So instead of stopping there, I wanted to see how this actually works end to end.

Tracing a real backend request

Let’s assume there’s a backend deployed on AWS.

It’s serving something simple — maybe a /users endpoint that returns some sample data.

If you open the browser’s network tab, refresh the page, and disable cache, you see a request go out… and a response come back.

At that moment, the obvious question becomes:

Where did this request actually go?

1. The domain name and DNS

The request starts with a domain name.

Something like:

backend-demo.xyz

Here, backend-demo is a subdomain.

That immediately brings DNS into the picture.

DNS is a massive topic, so keeping it simple:

A records point directly to an IP address
CNAME records point to another domain

In this case, there’s an A record:

backend-demo.xyz → <some IP address>

That IP address belongs to an AWS machine.

2. The AWS EC2 instance

That IP resolves to an EC2 instance.

Inside the AWS console:

you can see the instance
you can see its public IP
and that IP matches what DNS is pointing to

So now the request knows where to go.

But it still hasn’t reached the application.

3. The firewall (security groups)

Before the request touches the machine, it passes through a firewall.

In AWS, this is handled by security groups.

Security groups define:

which ports are open
which ports are accessible over the internet

Typically:

port 22 → SSH
port 80 → HTTP
port 443 → HTTPS

If ports 80 or 443 are not allowed, the request dies here.

It never reaches your server.

This is an important checkpoint.

4. Reaching the machine

Once the request:

resolves via DNS
passes through the firewall

It finally reaches the EC2 instance.

But even now, it’s not inside your application.

5. The reverse proxy (Nginx)

Inside the instance, there’s usually a reverse proxy.

A reverse proxy:

sits in front of application servers
handles routing, redirection, SSL, and configuration
keeps things centralized

In this setup, Nginx is:

listening on port 80
redirecting traffic to 443 (HTTPS)
handling SSL certificates

More importantly:

it listens for requests to backend-demo.xyz
and forwards those requests to localhost:3001

6. The actual backend server

On the same machine:

a Node.js server is running
on port 3001
managed by something like pm2

From the machine’s perspective:

the backend is just a local process

If you run:

localhost:3001/users

You get the same response.

So domain names and Nginx are just ways to route internet traffic to a local process.

The full request journey (condensed)

Putting it all together:

Request starts in the browser
Browser resolves the domain via DNS
DNS points to an AWS IP
Request passes the AWS firewall
Reaches the EC2 instance
Hits Nginx (reverse proxy)
Gets forwarded to localhost:3001
Reaches the backend server

That’s a lot of hops.

When working locally, you skip most of this and hit localhost directly — but conceptually, the flow is the same.

Why do we even need a backend?

A simple example explains it better than theory.

Imagine scrolling through Instagram.

You see a post.
You click Like.

Your friend gets a notification.

Between that click and that notification, something has to:

identify who you are
identify whose post it is
store the action
trigger another action

That “something” is the backend.

If you strip the responsibility of a backend down to one word, it’s this:

Data

fetching data
receiving data
persisting data

Every meaningful action in an application revolves around data.

And that data has to live somewhere centralized.

Why not just do everything on the frontend?

At first glance, this feels like a great question.

Frontends run on computers too, right?

Why not:

connect directly to databases?
handle logic on the client?
distribute everything?

To answer that, it helps to understand how frontends actually work.

How frontends work, end to end

Consider a frontend app deployed on the same EC2 instance.

When you refresh the page, the browser first fetches:

an HTML document

After that, it fetches:

JavaScript files
CSS files
fonts
images

Each of these is a separate request.

Once:

CSS is loaded → the UI is painted
JavaScript is loaded → event listeners are attached

Only then do buttons start working.

Routing, clicks, interactions — all of that happens because the browser executes JavaScript.

That’s the key difference.

The runtime difference that changes everything

Backend:

code runs on the server
request comes in
server processes it
server sends a response

Frontend:

server sends code
browser runs that code
logic executes on the user’s machine

That leads to several hard constraints.

Why backend logic doesn’t belong in the frontend

1. Security

Browsers run in sandboxed environments.

They cannot:

access the file system
read environment variables
interact freely with OS processes

Backends often need exactly those things.

And this restriction exists for a reason.

Browsers execute remote code.
If that code wasn’t isolated, it could:

read user files
steal sensitive data
send it elsewhere

That would be disastrous.

2. CORS and external APIs

Browsers enforce CORS policies.

Frontend JavaScript:

cannot call arbitrary external APIs
unless the correct headers are present

Backends don’t have this restriction.

Backend servers often need to:

talk to many other services
aggregate data
integrate with third-party systems

CORS alone makes frontend-only backends impractical.

3. Databases and connections

Backend runtimes:

have native database drivers
handle sockets and binary protocols
maintain persistent connections

They use connection pooling:

reuse connections
avoid overwhelming the database

Browsers:

cannot maintain database connections efficiently
are not designed for pooling

If every user opened their own database connection, the database would collapse under load.

4. Computing power and consistency

Frontends run on:

phones
laptops
low-powered devices
unpredictable environments

Backends:

are centralized
can scale CPU and memory
handle heavy workloads consistently

Relying on client machines for core logic simply doesn’t work.

Where this leaves things

Even if it were technically possible to move backend logic into the frontend:

it wouldn’t be secure
it wouldn’t scale
it wouldn’t be reliable

At this point, it becomes clear:

what a backend is
why it exists
how it works
and how it fundamentally differs from the frontend

This feels like the right starting point before going deeper.

From here, the next step is understanding:

the principles
the trade-offs
and why learning backend engineering as a system makes more sense than learning it as a set of APIs.