Phase 0
What is "the backend" actually made of?
Unpack the word backend into its real parts: the app server, the database, the cache, and the queue.
"The backend" is at least four different things
Say "the backend is slow" and you've said almost nothing useful, because "the backend" isn't one system - it's shorthand for a handful of distinct pieces, each with its own job, its own failure modes, and its own reason for being slow. Knowing what those pieces actually are is the difference between a vague complaint and an actual starting point for debugging.
Interactive example
One request across the pieces
At rest the cache has the answer. Hover to make it a miss and watch the request fall through to the database.
On a hit the request never reaches the database, which is the entire reason the cache is there. On a miss the app falls through to the database, sends the response, and usually writes the value into the cache so the next request takes the short path.
The application server: where your logic lives
This is the part most people picture when they say "backend" - the running process executing your code, deciding what a request should do, and producing a response. It's a Node process, a Django app, a Spring Boot service - whatever framework, this is the layer that holds your actual business rules: is this user allowed to do this, what does this endpoint return, what should happen next.
On its own, the application server usually doesn't store anything permanently. It's the coordinator, not the memory.
The database: where state actually lives
Data that needs to survive a restart - user accounts, orders, posts, anything you'd be upset to lose - lives in a database, not in the application server's memory. This is deliberate separation: the app server can crash, redeploy, or scale to twenty instances, and none of that touches the data, because the data was never inside it in the first place.
This is also why "the database is slow" and "the app is slow" are different bugs requiring completely different fixes - one is a query problem (missing index, bad join, lock contention), the other is application logic doing too much work before it even reaches the database.
The cache: a deliberately unreliable shortcut
A cache sits between the app server and the database, holding a copy of data that's expensive to fetch but doesn't change often, so repeated requests don't have to hit the database every time. Redis and Memcached are the common examples.
The queue: where work waits its turn
Not every request needs an immediate answer. Sending a confirmation email, resizing an uploaded image, generating a report - a message queue (RabbitMQ, SQS, Kafka) lets the app server hand off that work and respond to the user immediately, while a separate worker process picks up the job whenever it gets to it.
This is the piece most tutorials skip entirely, which is exactly why "why is my APIAPIA defined way for one piece of code to ask another to do something, without needing to know how it happens internally. Not a specific technology - a function signature, a library's exports, and a REST endpoint are all APIs. slow" so often turns out to be "because it's doing work synchronously that should have been queued instead."
Putting the four pieces together
A typical request touches some subset of all four: the app server receives it, checks the cache first, falls back to the database on a miss, maybe queues a background job before responding, and sends the response back - often in under a hundred milliseconds, across pieces that don't even run on the same machine.
None of these four pieces is optional in a real system, and none of them is "the backend" by itself. The word describes the whole assembly - which is exactly why vague backend complaints are so hard to act on, and specific ones (the database, the cache, the queue, the app logic) are so much easier to actually fix.