In Episode #1 we followed one request on its full journey — DNS, TCP, HTTPS, and finally a server that did some work and sent back a page.
Missed it? Start here:
Today we zoom into that server. Because there is a question that sounds obvious — until someone asks it in an interview and your mind goes blank:
"What is a backend? And why do we even need one?"
Browsers today are incredibly powerful. They run 3D games. They edit videos. They have their own storage, their own databases, their own everything.
So why can't the browser just be the whole app?
By the end of this episode, you'll have an answer you can explain to anyone — and I'll also settle the 5 questions I left you with last time.
🍽️ The Restaurant, Properly This Time
In Episode #1, I briefly compared the server to a restaurant kitchen. Let's now build the full picture, because this one analogy explains almost everything.
A restaurant has two worlds:
The dining hall — beautiful tables, a menu, a waiter who takes your order. This is everything the customer sees and touches.
The kitchen — the recipes, the ingredients, the pantry, the locked cash box. Customers never enter. There is literally a door with a "STAFF ONLY" sign.
Every app you have ever used is built exactly like this:
The frontend is the dining hall. It runs on your device — your browser, your phone. Buttons, forms, colors, animations. Its job is presentation: take your order, and serve the plate nicely.
The backend is the kitchen. It runs on computers you will never see. It holds the recipes (business logic), the pantry (the database), the gatekeeper (authentication), and the safe (secrets and keys).
And the waiter walking between the two worlds, carrying orders in and plates out?
That's HTTP — the request/response cycle from Episode #1.
🚪 The One Sentence That Explains Everything
Here it is. If you remember nothing else from this episode, remember this:
The frontend runs on the user's machine. The backend runs on yours.
Why does that one sentence matter so much?
Because anything that runs on the user's machine belongs to the user.
They can read it. They can copy it. They can modify it. Every line of JavaScript, every hidden field, every "please don't touch this" comment — it is all sitting on their device, fully under their control.
The backend is the only part of your app that users cannot open, cannot read, and cannot edit.
Which means it is the only place where you can keep:
- Truth (the real data)
- Rules (the real logic)
- Secrets (the real keys)
Now let's use this one idea to answer all 5 questions from last episode.
🏦 Question 3 First — The Bank Balance Experiment
"If DevTools lets me edit any website live on my screen, why can't I change my bank balance?"
You absolutely can change the number on your screen. Try it! Open your bank's website, press F12, find the balance, type ₹99,99,999.
Congratulations — you are rich.
For about four seconds.
Here is why it means nothing. What you edited was your local copy — pixels on your machine. The bank's actual record of your money never left the bank's server.
The moment you try to do anything — withdraw, transfer, even refresh the page — your browser must send a request across the wire. And on the other side, the server ignores your beautiful edited number completely. It checks its own database, sees ₹500, and calmly replies:
403 Forbidden — nice try.
This gives us the golden rule of backend engineering:
The frontend is a suggestion. The backend is the decision.
Editing the frontend is like crossing out the price on a restaurant menu with your own pen and writing "₹1". The kitchen doesn't care. The billing counter runs on their price list, not your menu.
📱 Question 2 — Where Does Your Instagram Feed Live?
"When you check Instagram, where does that data actually live — on your phone, or somewhere else? And why there?"
Think about what you expect from Instagram:
- You post from your phone, and your friend in another city sees it instantly
- You log in from a brand-new phone, and everything is still there
- You and 2 billion other people see one consistent world
None of this is possible if the data lives on your phone.
If your feed lived on your device, your friend's phone would have no way to know about your new post. Every phone would hold its own little disconnected universe.
Shared data needs a shared home — one central place that every device reads from and writes to. That home is the backend's database.
Your phone holds, at most, a temporary copy (a cache — Episode #1's favorite idea) so scrolling feels fast. The truth lives on the server.
This is backend job #1: keep the data in one place, so everyone sees the same world.
🎬 Question 4 — Same URL, Different Content. How?
"Two users open the same website at the same moment and see completely different content. Same URL, same server — how?"
Because the URL is not the whole request.
Remember the HTTP request from Episode #1? It carried a cookie:
GET / HTTP/1.1
Host: instagram.com
Cookie: session=xyz789
When you logged in, the server gave your browser a cookie — think of it as a coat-check token. Your browser attaches it to every future request automatically.
So when two people request the same URL:
- Request A arrives carrying your token → the server looks it up → "this is Kush" → builds Kush's feed
- Request B arrives carrying her token → "this is Aditee" → builds Aditee's feed
Same door, same restaurant — but the waiter recognizes each regular customer and brings their usual order.
The page you see is not a file sitting on a server. It is cooked fresh, per person, per request — by backend logic.
✅ Question 5 — Why Validate Twice?
"Frontend validation already checks the email format. Why does the server check it again?"
Here is the uncomfortable truth: attackers don't use your frontend.
Your pretty form with its red error messages? That's just one polite way to talk to your server. Anyone can skip it entirely and speak to your API directly:
curl -X POST https://yourapp.com/api/register \
-H "Content-Type: application/json" \
-d '{"email": "not-an-email-lol", "age": -50}'
One line in a terminal — and every frontend check you wrote is bypassed. Never ran. Doesn't exist.
So what is frontend validation for? Politeness. It gives honest users instant feedback without a round trip. It is a UX feature.
Backend validation is the actual security. It is the airport: you check your passport at home (convenient), but the airport checks it again at the gate (mandatory) — because the airport cannot trust that everyone checked at home.
Rule: frontend validation is for user experience, backend validation is for survival.
💪 Question 1 — So Why Can't the Browser Be Everything?
Now we can answer the big one properly.
"Browsers can run 3D games and edit videos. Why does a server need to exist at all?"
Because power was never the problem. The browser fails for reasons no amount of power can fix:
1. Shared data needs one home. Your feed, your messages, your orders — every device must see the same truth (Question 2).
2. Someone neutral must referee. Two people grab the last movie seat in the same second. Two browsers can't settle that argument — a single central authority must decide who clicked first. (This gets a whole episode later: it's called a race condition.)
3. Secrets can't be shipped. Your app's payment keys, database passwords — anything sent to a browser can be read by anyone with F12. Secrets can only live where users can't look.
4. Nothing from the client can be trusted. Questions 3 and 5. The backend is the last line of defense.
5. Heavy work needs big machines. Searching a billion rows, resizing videos, sending 10,000 emails — no phone battery should ever do that.
So even in a world of super-powerful browsers, we would still need backends. Not for power — for shared truth, neutral refereeing, and trust.
🎯 What Interviewers Ask About This
This exact topic, as it appears in real interviews:
1. "What's the difference between frontend and backend?"
Weak answer: "frontend is what you see, backend is behind the scenes." Strong answer: where the code runs — frontend runs on the user's device (untrusted), backend runs on servers you control (trusted). Everything else follows from that.
2. "Why can't we do authorization on the frontend?"
Because the user controls the frontend. Hiding a button is cosmetic; the API behind it must do the real check, or anyone with curl walks right past your UI.
3. "Client-side vs server-side validation — do we need both?"
Yes. Client-side for instant UX, server-side for security. Only the server-side one is mandatory.
4. "Where should sensitive keys be stored?"
Only on the backend (environment variables / secret managers). Anything in frontend code is public, no matter how well hidden.
🌱 The Key Idea Behind It All
A backend is not "the hard part" or "the part with databases."
A backend is simply: the part of your app that runs on machines the user cannot touch.
That single property — out of the user's reach — is what makes it the only possible home for:
- Truth — the real data, shared by everyone
- Rules — logic that no one can skip
- Secrets — keys that no one can read
The frontend proposes. The backend decides.
This concludes Episode #2 of Backend Odyssey, a series that starts from the very beginning and slowly explores what really happens behind the scenes when you use the internet.
Episode #3 is "Client vs Server — Explained With a Real Example" — we take one real app and trace a complete conversation between client and server, message by message, so you can see exactly who says what, and when.
Before you go — here are 5 questions to sit with. Try answering them in the comments; Episode #3 answers all five:
- Your phone, your laptop, and your smart TV can all be "clients." What exactly makes something a client — the device, or something else?
- Can a server also be a client at the same time? (Hint: think about what happened in Episode #1, Step 5.)
- When you're typing in Google Docs and your friend sees your letters appear live — is that still request/response? Who is asking whom?
- A food delivery app shows the rider moving on the map every few seconds. How does your phone keep getting fresh locations — does the server "push," or does your phone keep "pulling"?
- If the server is so important, what happens to the app when the server goes down — and why do some features still work offline?
Think you know some of these? Drop your answers below — I'll tell you if you're right in Episode #3, and the best answers get a shoutout.
If you found it useful, follow and subscribe to receive future episodes as they are published.
– Your friendly neighbourhood KS 🕸️
Top comments (0)