Start from zero: what a backend actually is
A backend is the program that answers requests on a server — the half of the web you never see. This is the from-zero map and the eight words Unit 01 and every unit after it assumes you already know.
You open a browser, type a URL, and a webpage appears. You log in and your profile shows up. You click “buy” and a confirmation email arrives seconds later. None of that happens in your browser. Somewhere a program on a machine you will never see received your click, figured out what you wanted, asked a database, and wrote back an answer — all in under a second. That program is the backend. Everything in this track exists to teach you how to build one that is fast, correct, and does not fall over when things go wrong. This lesson is the map before the climb.
By the end of this lesson you will have the eight terms that every senior unit assumes — so when they appear in context, you already know what role each one plays.
The one problem a backend solves
A web browser can display HTML and run JavaScript, but it cannot safely store passwords, charge a credit card, or hold a shared database that all users read and write. Someone has to live outside the browser, remember things across sessions, enforce rules, and answer everyone’s questions consistently. That someone is the backend: a program running on a machine in a data centre, reachable over the network, waiting for requests and replying with data.
When you think about it, every backend feature you will learn — authentication, caching, rate limiting — is just a more specific answer to one of those constraints.
Everything else this track teaches — middleware, async I/O, connection pools, circuit breakers — is detail on top of that single job: receive a request, do useful work, return a response, survive the load.
The eight words the rest of the track assumes
The senior units ahead drop these terms without stopping to define them. Here they are, one sentence each — what it is and why it exists.
| Word | What it is | Why it exists |
|---|---|---|
| Server | A program (or machine) that listens for network connections and answers them. | So many clients can reach your code without running it themselves. |
| Request / Response | The two-message conversation: a client asks, the server answers. | So client and server can live on different machines and still talk. |
| HTTP method | A verb on the request — GET, POST, PUT, DELETE — that signals intent. | So the server knows whether the client is reading, creating, or removing data. |
| Endpoint / Route | A URL path + method pair the server promises to handle (e.g. POST /orders). | So the client knows where to aim each kind of request. |
| Handler | The function that runs when a request matches a route. | So each route has its own piece of logic, easy to read and test. |
| Status code | A three-digit number on the response (200 OK, 404 Not Found, 500 Error). | So the client can react correctly without parsing the body to detect failure. |
| Database | Persistent storage the backend reads from and writes to across requests. | So data survives restarts and is shared across all users and server instances. |
| Statelessness | Each request carries everything the server needs to answer it; no memory between calls. | So any server instance can handle any request, making scale-out and restarts safe. |
How they fit together
Read in order, the words tell one story: a request arrives carrying an HTTP method and a URL; the server’s router matches that URL to an endpoint and calls the handler function; the handler reads or writes the database and builds a reply; the reply goes back as a response with a status code the client checks. Because the server is stateless, it remembers nothing between calls — all context either travels in the request itself or lives in the database. That single paragraph is the entire track in miniature; every unit ahead zooms into one step.
▸Why this works
Why does statelessness matter if it just shifts the burden to a database? Because a stateful server is a bottleneck: every user’s second request must reach the same machine that handled the first, or their session data is lost. A stateless server has no such constraint — any instance can answer any request, so you can add more instances when traffic spikes and remove them when it drops, with zero coordination. The database handles the shared truth; the server stays disposable.
You do not need to memorise this
Two honest notes before the climb. First: nobody holds all of this perfectly on day one — you will meet each word again in its own unit, deeper, and it will stick then. This page is a coat-hook to hang the details on, not a test. Second: not every backend needs every feature. A tiny side project might be a single server with three routes and no load balancer. The track teaches the full picture because that is what production under load demands — but “start simple, add complexity when the pain shows up” is itself the senior instinct.
Why must a backend server be stateless — what does that enable?
Order the journey from a client click to a response arriving back:
- 1 Client sends a request with an HTTP method and URL
- 2 Router matches the URL to an endpoint and calls the handler
- 3 Handler reads or writes the database
- 4 Server sends a response with a status code and data
- 01In one breath, what is a backend and why does it have to exist?
- 02Trace the path of a request from the moment a client sends it to the moment a response arrives, naming each concept.
A backend is one idea with a lot of machinery hung off it: a program on a server receives requests, runs logic, reads or writes a database, and returns responses — all while keeping no memory between calls so any server instance can handle any request. The eight words map the full surface: a server listens; a request carries a method and a URL; the router matches it to an endpoint and fires the handler; the handler talks to the database; a response with a status code goes back; and statelessness keeps the whole thing scalable. Now when you see any of these eight terms in a senior unit, you will know exactly which step of that cycle it belongs to — and you will know what breaks when that step goes wrong.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.
Apply this
Put this lesson to work on a real build.