Build the mental model
These three words get confused constantly, but they mean genuinely different things. A database stores data — nothing more, nothing less. A backend contains the server-side application logic: validation rules, calculations, business decisions. An API is the interface through which systems talk to each other — a contract, not a place where data lives.
The typical flow: Frontend -> API -> Backend -> Database. A user clicks a button in the frontend; that sends a request through an API; backend code decides what to do; the backend then reads or writes the actual data in the database.
| Layer | Job |
|---|---|
| Database | Stores and organizes the actual data; it does not decide what a request is allowed to do |
| Backend | Runs server-side logic: validates input, applies business rules, and decides what to read or write |
| API | Defines the interface/contract other systems use to ask the backend to do something |
Common beginner mistake
Saying 'the backend' when you mean 'the database,' or assuming an API is itself a database, is a common mistake. An API almost never stores anything — it's a doorway, not the room behind it.
All three layers can change independently — you can swap the database product, or expose a different API on the same backend. This is exactly why teams can split responsibility for each layer among different engineers.
REQUEST FLOW: FRONTEND TO DATABASE
----------------------------------
REQUEST FLOW: FRONTEND TO DATABASE
------------------------------------
[ Frontend ] -- request --> [ API ]
|
v
[ Backend ]
(validation, business logic)
|
v
[ Database ]
(stores the data)Connect it to a real scenario
This distinction tells you where to even start looking when debugging. 'My data isn't saving' usually points at the database or backend write logic; a 404/500 error usually points at the API layer or backend route handling.
'The request succeeded but the numbers are wrong' often points at backend calculation logic, not the database. Naming which layer a symptom belongs to is a genuinely useful debugging skill.
One person can wear all three hats
On a small project, one person can design the database, write the backend, and define the API — the three roles stay conceptually distinct even so.
Try the working example
function classifyResponsibility(description) {
const text = description.toLowerCase();
const apiHints = ["endpoint", "other apps", "expose", "http request", "public interface"];
const databaseHints = ["store", "persist", "save", "table", "row", "record", "durable"];
const backendHints = ["validate", "calculate", "business rule", "process", "authoriz", "authenticat"];
const matchesAny = (hints) => hints.some((hint) => text.includes(hint));
if (matchesAny(apiHints)) return "API";
if (matchesAny(databaseHints)) return "Database";
if (matchesAny(backendHints)) return "Backend";
return "Unclear";
}
const tasks = [
"store user records permanently",
"validate a password before login",
"expose an endpoint other apps can call",
"calculate shipping cost based on cart items",
"save a new order permanently",
];
for (const task of tasks) {
console.log(`"${task}" -> ${classifyResponsibility(task)}`);
}"store user records permanently" -> Database
"validate a password before login" -> Backend
"expose an endpoint other apps can call" -> API
"calculate shipping cost based on cart items" -> Backend
"save a new order permanently" -> Database5-minute try-it
Run classifyResponsibility against three responsibilities from your own project and check whether the Database/Backend/API classification matches reality.
One important caution
Using 'the backend' as a synonym for 'the database' — the two layers are genuinely different
Assuming an API stores data the way a database does
Quiz: Which layer is which
Wikipedia: API — How Databases Work