What a backend does
Every app you use has a hidden half that stores data, enforces rules and talks to other systems. Learn what the backend is, what it does on each request and how it fits with the frontend and database.
Think of a restaurant. The dining area is what customers see: menus, tables, a friendly waiter. The kitchen is where food is actually made, ingredients are stored and the rules of the house are followed. Customers never walk into the kitchen.
In software, the frontend is the dining area (the web page or mobile app) and the backend is the kitchen. The backend is code running on a computer you control (a server) that receives requests, applies rules, reads and writes data and sends back a response.
The big picture
Most apps have three layers:
1. Client: the browser or mobile app. It shows screens and collects input. 2. Server (backend): your code. It decides what is allowed and what the answer is. 3. Database: where data lives permanently (users, orders, messages).
The client talks to the server over the internet using HTTP (covered in *HTTP in depth* next). The server talks to the database using queries. The client never talks to the database directly.
Who does what
| Layer | Runs where | Job | Brew & Bean example |
|---|---|---|---|
| Client | User's phone or browser | Show the menu, collect the order | React page with a Place order button |
| Backend | Your server | Check the order, compute the total, save it | FastAPI or Express app |
| Database | Server or managed service | Store data safely | Table of menu items and orders |
Why not do everything in the frontend?
Anything running in the user's browser or phone can be read and changed by the user. So the backend exists for things you cannot trust the client with:
- Rules and calculations. Brew & Bean's order total must be computed on the server from real prices. If the browser sent total: 1, a customer could pay ₹1 for everything.
- Secrets. API keys, database passwords and payment keys must never ship to the browser.
- Shared data. Two customers on two phones must see the same menu and the owner must see every order. That needs one central place.
- Identity. Only the server can reliably decide who you are and what you may do.
- Heavy or private work. Sending email, charging cards, calling AI models, resizing images.
Never trust the client
Treat every value that arrives at your backend as untrusted input: it may be missing, wrong, or deliberately malicious. Validate it, and recompute anything that matters (prices, permissions) on the server.
What happens on one request
Follow a customer placing a Brew & Bean order. The steps are the same for almost every backend.
Life of a request
- 1The browser sends
POST /orderswith a JSON body listing the items, the name and the phone number. - 2The server receives the request and routes it to the function that handles
POST /orders. - 3The code checks the input (is the phone number present? do the item ids exist? is the quantity at least 1?).
- 4It checks who is calling and whether they are allowed (authentication and authorisation).
- 5It looks up the prices in the database and computes the total.
- 6It saves the new order in the database.
- 7It may trigger side effects, such as sending a notification to the kitchen.
- 8It builds a response: status
201 Createdand the saved order as JSON. - 9The browser receives the response and shows "Order received".
Notice that the client sent a request and got exactly one response. The server does not push things to the client on its own, unless you add special techniques such as WebSockets (covered later in the track).
What backend developers actually build
Typical backend responsibilities
| Area | Question it answers |
|---|---|
| APIs | What URLs does the client call and what do they return? |
| Data | How is information modelled, stored and queried? |
| Auth | Who is this user and what can they do? |
| Validation | Is this input acceptable? |
| Performance | How do we stay fast with many users (caching, indexes)? |
| Reliability | What happens when something fails (logging, retries, monitoring)? |
| Security | How do we protect data and block abuse? |
| Deployment | How does the code get running on a server and stay running? |
This track covers each of these. You will build APIs in both Node.js (Express) and Python (FastAPI), so you can pick whichever fits your job search. The ideas are the same in every language.
Languages and frameworks
You can write a backend in almost any language. Common choices include JavaScript or TypeScript with Node.js, Python, Java (often with Spring Boot), Go, C# and PHP. A framework such as Express, FastAPI, Spring Boot or Django gives you the repeated parts (routing, parsing requests, building responses) so you write only your own logic.
Do not agonise over the choice. Learn one well; the concepts (HTTP, REST, SQL, auth, caching) transfer directly to the others.
Stateless servers
A good rule: the server should not remember anything between requests in its own memory. Each request carries what is needed (such as a token saying who you are) and anything that must last goes into the database. This is called being stateless.
Why it matters: when traffic grows you run several copies of the server behind a load balancer. If one copy remembered your cart in its memory, your next request might reach a different copy and the cart would vanish. State in the database works with any copy.
How this comes up in interviews
Freshers are often asked: "What happens when you type a URL and press Enter?" or "Explain the difference between frontend and backend." A strong answer follows the request through DNS, the HTTP request, the server code, the database and back, and mentions why validation and secrets live on the server. Another common question is "Why is the server stateless?" and the answer is the load balancer example above.
Try it: Trace a request
Pick an app you use daily (for example a food delivery or UPI app). Write down what happens, step by step, when you tap one button such as "Place order". For each step say whether it happens in the client, the backend or the database. List two things the backend must check before accepting it.
Try it: Spot the unsafe design
A small shop's frontend sends this to the server when a customer pays: {"item": "cold-brew", "qty": 2, "price": 220, "total": 440}. What is wrong, and how should the backend treat these fields?
Key takeaways
- The backend is server code that receives requests, applies rules, uses the database and returns responses.
- The client is never trusted: validate input and recompute anything important on the server.
- Secrets, shared data, identity and heavy work belong on the backend.
- One request leads to one response; the same life-cycle (route, validate, authorise, work, respond) appears in every framework.
- Keep servers stateless so you can run many copies; store lasting state in the database.
- The language matters less than the concepts: HTTP, REST, SQL, auth, caching and deployment.
Check yourself
Finishing the quiz marks the lesson as done.
1. Why should a shop's order total be computed on the server rather than trusted from the browser?
2. Which of these should never be placed in frontend code?
3. What does it mean for a server to be stateless?
4. In the usual three-layer setup, how does the client get data from the database?
5. Which step belongs in the backend's handling of POST /orders before saving?
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.