Backend 101: What It Is and Why It Exists

Open any app. Instagram, Uber, Amazon. Tap something. Behind that tap, a computer somewhere processed your action. That computer is what we call the backend.

The Simple Version

A backend is a computer that’s always running, always listening. It waits for requests over the network, processes them, and sends back a response.

You type a URL, your request travels across the internet, hits a server, the server does some work, sends you the result.

We call it a “server” because it serves things. JSON data, HTML pages, images, whatever the client asked for.

The Journey of a Single Request

You type myapp.com/users in your browser. Between that keystroke and the data appearing on your screen, here’s what actually happens:

DNS: “Where does this domain live?” Your browser doesn’t speak human domain names. It needs a numeric IP address. So it asks a DNS server, which is basically the internet’s phone book. “What’s the IP for myapp.com?” The DNS says “54.23.115.80.” Now your browser knows where to go.

Fun fact: your OS caches DNS results. So this lookup only happens the first time (or after the cache expires). That’s why clearing your DNS cache sometimes “fixes” websites.

Firewall: “Are you allowed in?” The request hits the server’s front door. A firewall (AWS calls these Security Groups) checks: are you coming on port 443 (HTTPS)? Allowed. Port 80 (HTTP)? Maybe. Random port? Blocked. Go away.

This is your first line of defense against bots, scanners, and attackers that constantly probe the internet.

Reverse Proxy: “Which app do you want?” Inside the server, Nginx or a similar tool acts as a traffic cop. One machine might run multiple apps. The proxy looks at the domain in your request and routes it to the correct application. api.myapp.com goes to port 3001, admin.myapp.com goes to port 3002.

It also handles SSL termination (decrypting HTTPS), load balancing, and rate limiting so your actual app doesn’t have to worry about any of that.

Your Application: “Finally, the actual work” Your Node/Java/Go/Python process on localhost:3001 receives the request, runs your code, hits the database, and sends a response back up the chain.

All of this takes under 100 milliseconds for a typical request. Five systems coordinated seamlessly so it feels instant to you.

But Wait, Why Can’t the Frontend Just Do Everything?

The browser already runs JavaScript. It already has computing power. Why can’t it just talk to the database directly and skip this whole “server” thing?

Great question. And the answer reveals why backends MUST exist:

1. Browsers live in a jail cell (on purpose) When you visit a random website, that site’s JavaScript runs on YOUR computer. Think about how terrifying that is. If the browser didn’t restrict what JS can do, any shady website could read your files, steal your passwords, access your webcam.

So browsers lock JavaScript in a “sandbox.” No file system access. No raw network sockets. No environment variables. Limited API calls due to CORS. Your frontend code is powerful but intentionally caged.

Backends have no cage. Full OS access. They can read files, maintain persistent database connections, call any API, access secrets. Because they run on YOUR controlled infrastructure, not on a stranger’s computer.

2. Connection math doesn’t add up Your backend maintains maybe 20 persistent database connections in a pool and reuses them for thousands of requests per second. Efficient.

If 10 million users’ browsers each opened a direct connection to PostgreSQL? The database would catch fire. It can handle a few hundred connections max. The backend acts as a multiplexer: many users, few connections.

3. Some work needs real muscle Processing a 10MB image upload into 5 different thumbnail sizes? Running an ML model? Generating a complex PDF? Your user’s phone with 3GB RAM can’t handle that. A server with 64GB RAM and 32 cores can do it in under a second.

4. Coordination requires a central brain When you like your friend’s post on Instagram, YOUR phone needs to talk to YOUR FRIEND’S phone. But phones can’t talk directly to each other. There has to be a middleman, a centralized system that knows all users, all posts, all relationships. That’s the backend.

It’s All About Data

If you zoom out far enough, every backend on earth does some combination of four things:

1. Receives data from user input, other services, webhooks, file uploads
2. Validates and transforms data like checking if an email is valid, converting CSV to JSON, sanitizing HTML
3. Persists data by saving to PostgreSQL, writing to Redis, uploading to S3
4. Sends data back to the client, pushes notifications, triggers webhooks

Netflix, Uber, your company’s internal tool, a simple blog. All just data in, processing, data out. The complexity varies wildly, but the fundamental job never changes.

What Makes a Backend “Production-Ready”?

A toy backend receives a request, queries the database, returns JSON. Done in 20 lines.

A production backend adds:

• Authentication (who are you?)
• Authorization (what can you do?)
• Validation (is your data even valid?)
• Error handling (what if the DB is down?)
• Logging (what happened and when?)
• Rate limiting (are you spamming me?)
• Caching (don’t hit the DB for the same data 10,000 times)
• Monitoring (is anything broken right now?)
• Graceful shutdown (don’t drop requests during deploys)

That’s what we’ll cover in this series. Not just “how to make it work” but “how to make it work when 100,000 people are hitting it simultaneously and things are going wrong.”

Quick Recap

• Backend = a permanently running computer that processes requests
• Requests travel through DNS, Firewall, Reverse Proxy, then finally Your App
• Browsers are intentionally limited (sandbox), that’s why backends exist
• The backend’s core job is always data: receive, process, store, send
• Production backends are 10% business logic, 90% infrastructure concerns

Day 1 of 95 | Backend Engineering Series