The one idea
Software is not one thing. It is a small number of parts, each responsible for something different, passing messages to each other.
When you can name which part is responsible for what, "it's broken" becomes a specific, answerable question. That is the entire value of this lesson.
One part shows you things. One part decides things. One part remembers things. They talk to each other over the internet.
Frontend displays and collects. Backend applies rules and decides. Database stores. The API is the agreed way the frontend asks the backend for something. Hosting is whose computer all of it runs on.
A client renders an interface and issues requests over HTTP to a server, which validates input, applies business logic, and persists state to a datastore. The API is the request/response contract between them.
The five parts
| Part | Responsible for | Fails like |
|---|---|---|
| Frontend | What you see and click. Collecting input. | Button does nothing, layout broken, page blank |
| Backend | Rules, decisions, permissions, calculations | Wrong result, "something went wrong", nothing saves |
| Database | Remembering. Storing and retrieving data. | Data missing, duplicated, or out of date |
| API | The agreed way frontend asks backend | 404, 500, "network error", request times out |
| Hosting | Whose computer this runs on, and its address | Site unreachable entirely, slow for everyone |
Notice that each failure looks different from the outside. That is what makes this diagnostic and not just vocabulary.
Following one booking
Take a real thing: a form on a clinic's website. Name, phone, date, a Confirm button. Here is what actually happens in the second after you click.
From click to stored booking
1 of 5The frontend collects and checks the obvious things.
The frontend is the code running inside your browser — the HTML that describes the fields, the CSS that makes them look like something, and the JavaScript that reacts when you type. It notices you left the phone number blank and shows red text before anything leaves your computer.
This check is for your convenience, not for safety. Anyone can bypass it. Which is why the backend has to check again.
Where hosting fits
All that backend and database code runs on a computer that is switched on all
the time and reachable from the internet. Renting that computer is hosting.
The readable address people type — clinic.example.com — is a domain, which
is separately rented and pointed at that computer.
In an interview you are asked "where is the data stored?" about a project you built. The answer that lands is not "in the cloud". It is: "user input goes from the browser to my backend, which validates it and writes it to a Postgres database hosted on the same provider as the app." Same project. One of these answers tells them you understand what you built.
A vendor says your customer data "never leaves your browser". That is a checkable claim. If the data survives a page refresh on a different device, it went to a backend and a database. If it does not, it really was local. Knowing the parts lets you test the claim instead of believing it.
Try this
For each symptom, name the most likely part at fault.
- The page loads, the form appears, but clicking Confirm does absolutely nothing.
- The confirmation appears, but the booking is not in the clinic's list.
- The whole site shows "server not found".
- Two people booked the same slot.
Your challenge
Level 3 · IndependentPick any website you use that stores something for you — a food delivery app, a college portal, an e-commerce site.
Write five lines, one per part, saying what that specific system's frontend, backend, database, API and hosting are responsible for. Then write one sentence per part describing what you would see if only that part failed.
You have succeeded when someone else could read your five failure descriptions and correctly guess which part each one refers to.
What people usually get wrong
- Calling everything "the website". It hides the only useful information in the report. Say what you saw and at what point.
- Assuming frontend validation is security. It is a courtesy to the user. The backend must check everything again, because the user controls the frontend.
- Thinking the database is the backend. They are separate, often on separate machines. A database can be fine while the backend that talks to it is down.
- Believing "it's in the cloud" is an answer. The cloud is someone else's computer with a rental agreement. The question is still which computer, where, and who can read it.
- Assuming static means simple means worse. A page with no backend cannot leak a database. Fewer parts is often the right design, not a lesser one.
How someone experienced does it
Experienced people ask "where does the truth live?" before anything else. In the booking system, the truth is the database row. Everything else — what the screen shows, what the confirmation email said, what is in the backend's memory — is a copy that can be stale or wrong.
Most confusing bugs are two copies of the truth disagreeing. The page says booked, the database says free. Once you look for that specifically, a whole class of "weird" behaviour becomes obvious.
They also assume the network will fail, because it does. The request that disappears halfway is not an edge case — it is Tuesday. Good systems are built so that a half-finished booking either fully happens or fully does not.
Static sites, dynamic sites, and why the difference matters
A static site is files that already exist — HTML, CSS, images — handed to your browser exactly as they are stored. Every visitor gets the same bytes. No backend, no database. A portfolio, documentation, a brochure site.
A dynamic site builds the response when you ask. Your feed is different from mine because a backend queried a database with your identity.
This matters for three reasons. Static sites are cheap or free to host, because serving a file is nearly costless. They are far harder to attack, because there is no database to reach and no logic to trick. And they cannot do anything personal.
A large amount of over-engineering comes from building dynamic systems for static problems. If nothing changes per visitor and nothing is stored, you do not need a backend, and adding one buys you cost and risk with no benefit.
Prove it
Open a site you use, open your browser's developer tools, and go to the Network tab. Then do something that saves data — search, log in, add to cart.
Watch the requests appear. Pick one, and write down: the address it went to, the method (GET or POST), and what came back. You have just watched the frontend talk to the backend. That is the conversation this whole lesson is about.
Keep learning this
Paste this into any AI assistant. It turns the assistant into a tutor that tests you instead of just answering you.
Act as an experienced practitioner who is good at teaching. I have just learned how frontend, backend, databases and APIs fit together. Assume I am intelligent but relatively new to this — treat me as beginner level. Work through this in order, and wait for my reply at each step: 1. Ask me 5 questions that test whether I actually understood how frontend, backend, databases and APIs fit together. Do not reveal the answers yet. 2. After I answer, tell me which parts I got right, which I got wrong, and which I only half-understand. Explain only what I misunderstood — do not re-teach what I already know. 3. Give me one practical challenge based on something I could genuinely encounter at work or in daily life. Do not solve it for me. 4. Evaluate my solution the way an experienced person would judge it, including what a professional would have done differently. 5. Tell me what to learn next, and why that comes next. 6. Give me trustworthy sources for deeper study — prefer official documentation, primary research or standards bodies over blogs and videos. Rules for you: no buzzwords. No motivational filler. Say "I'm not certain" when you are not certain, and tell me which parts of your answer I should verify myself. Clearly separate facts from your recommendations and your opinions.
Become independent at this
Use this when you want a path from where you are to actually good, with checkpoints you can test yourself against.
I want to become independently capable at describing what a software system is made of — not permanently dependent on AI, tutorials or step-by-step guides. Design a progression for me with five stages: Beginner, Guided practice, Independent practice, Real-world application, Professional level. For each stage tell me: - what I must know - what I must be able to do without help - the mistakes people make at this stage - one practical challenge - one real project that would prove I reached this stage - one way I can test myself honestly Then tell me the signals that I am ready to move to the next stage, and the signals that I have skipped ahead too early. Keep the theory to the minimum I actually need. Focus on ability I can transfer to situations you and I have not discussed.