Backend Odyssey - Ep 03: Client vs server

In Episode #2 we learned the golden rule: the frontend runs on the user's machine, the backend runs on yours.

Today we make the picture sharper. We keep saying "client" and "server", but what do those words really mean?

Here is a small test. Your phone, your laptop, and your smart TV can all open YouTube. Are they all clients? And can one machine be a client and a server at the same time?

By the end of this episode, you will answer both without thinking. And I will also settle the 5 questions from last time.

🙋 The Only Definition You Need

Forget devices for a moment. Remember this one line:

The client is the one who asks. The server is the one who answers.

That is the full definition. Nothing about hardware. Nothing about size. Nothing about location.

Think of a shop. A customer walks in and asks for 2 kg of rice. The shopkeeper hands it over.

The customer is not a customer because of who they are. They are a customer because of what they are doing right now: asking. The shopkeeper is the shopkeeper because they are answering.

Same on the internet:

• Your phone asks Instagram for the feed. Right now, your phone is the client.
• Instagram's machine answers with 30 posts. Right now, that machine is the server.

Client and server are roles in a conversation, not types of machines.

That single idea answers Question 1 from last episode: what makes something a client is not the device. It is the act of asking.

🔁 Question 2: Can a Server Also Be a Client?

Yes. And it happens millions of times every second.

Remember Episode #1, Step 5? Your request reached the app server, and then the server turned around and asked the database a question:

SELECT * FROM articles ORDER BY created_at LIMIT 30;

Look at what just happened:

• To your phone, the app server is the server. It answers.
• To the database, the same app server is the client. It asks.

One machine, both roles, at the same moment.

Real life works the same way. A shopkeeper sells rice to you. But in the morning, that same shopkeeper went to the wholesale market and bought 100 kg of rice from a bigger seller. Seller in one conversation, buyer in another.

In a big app, this chain can be 4 or 5 levels deep. Your phone asks server A, server A asks server B, server B asks the database. Every arrow has a client side and a server side.

🍕 One Real Example, Traced Fully

Let us watch one complete conversation, message by message. You are ordering a pizza in a food app.

Tap 1: you open the menu.

Your app asks: GET /menu which means "show me the menu."

The server answers: 200 OK with a list of 25 pizzas, about 18 KB of data.

Tap 2: you add a pizza.

Your app asks: POST /cart which means "add 1 farmhouse pizza, size large."

The server answers: 200 OK, your cart total is now 499 rupees.

Tap 3: you place the order.

Your app asks: POST /order which means "place the order, pay from wallet."

The server checks your wallet balance in its database, sees 800 rupees, subtracts 499, and answers: 201 Created, order number 88231, arriving in 32 minutes.

Tap 4: you check the status.

Your app asks: GET /order/88231 which means "where is my pizza?"

The server answers: 200 OK, status is "baking", 24 minutes left.

That is the entire app. 4 questions, 4 answers.

Now notice something in that diagram. Something that should bother you a little:

The server never speaks first. It only ever answers.

The client always starts every conversation. Which brings us to the trickiest question from last time.

✍️ Question 3: Google Docs Feels Like Magic. Is It Still Request and Response?

You type a letter. Your friend, 1,200 km away, sees it appear in under 1 second. Nobody refreshed anything.

If the server cannot speak first, how did your friend's screen learn about your letter?

Here is the trick. Your friend's browser asked first. It just asked a very special question:

"Keep me updated. I will hold the line open."

Think of it like a phone call versus a text message. A normal request is a text: you ask, they reply, done. But your friend's browser placed a call to the server and never hung up. The line stays open.

Now when you type the letter "k":

1. Your browser sends it to the server (a normal request, you asked first).
2. The server looks at its list of open lines and sees your friend holding one.
3. The server speaks into that open line: "he typed k."
4. Your friend's screen updates. Total time: around 200 milliseconds.

So yes, even the magic is built on the same rule. The client opened the line first. The server never calls a stranger.

This open line technique is called a WebSocket. It gets its own full episode later in the series.

🛵 Question 4: How Does the Rider Move on Your Map?

Your food app shows the delivery rider crawling along the road, updating every few seconds. There are exactly 2 ways to build this:

Way 1: Pull (also called polling). Your phone simply asks again and again:

"Where is the rider?" ... "Where is the rider?" ... "Where is the rider?"

Say it asks every 5 seconds. That is 12 questions per minute. For a 30 minute delivery, that is 360 requests, and maybe 300 of them get the same answer as before. Wasteful, but very simple to build.

Way 2: Push (the open line). Your phone asks once: "keep me updated." The server then pushes only real changes: "moved", "moved", "reached your door." For the same 30 minute delivery, maybe 40 messages total and zero waste.

Most delivery apps actually use pull with a short gap, because it is simpler and a 5 second delay does not hurt anyone. Chat apps and multiplayer games use push, because a 5 second delay there would ruin everything.

This is your first real taste of a backend engineering decision. Both ways work. The job is picking the right one for the situation. Here, the numbers decide: 360 wasteful requests versus 40 useful messages, against how much harder push is to build.

🔌 Question 5: The Server Dies. What Still Works?

Imagine Instagram's servers go down for 10 minutes. Open the app. What happens?

• Scrolling posts you already loaded: works
• The like animation when you tap a heart: works
• Loading even 1 new post: dead
• Sending 1 message: dead
• Logging in on a new phone: dead

See the pattern? Everything that lives on your device keeps working. Everything that needs the shared truth from Episode #2 stops.

Your phone is like a water tank on your roof. If the city supply stops, you can still use whatever is in the tank. But the tank cannot refill itself.

Some apps prepare for this on purpose. Google Docs lets you keep typing with no internet, saves your changes in the phone's own storage, and syncs everything to the server when the line returns. That design has a name: offline first. Your changes wait patiently in the tank until the city supply is back.

🎯 What Interviewers Ask About This

This exact topic, as it appears in real interviews:

1. "Explain the client server model."

One line: the client asks, the server answers, and these are roles in a conversation, not types of machines. Then give the app server and database example to show one machine playing both roles.

2. "Can a server be a client?"

Yes. Every time your backend calls a database, a payment gateway, or another service, it is acting as a client in that conversation.

3. "What is polling? What are its drawbacks?"

Asking repeatedly on a timer. Simple, but wasteful: at a 5 second gap, 1 user costs 720 requests per hour even when nothing changes. Mention WebSockets as the push alternative.

4. "How would you build live order tracking?"

Show the tradeoff: polling every 5 seconds is fine for a delivery map, push is needed for chat. Interviewers love hearing that both are valid and the situation decides.

🌱 The Key Idea Behind It All

The whole internet runs on one tiny pattern, repeated billions of times per second:

Someone asks. Someone answers.

• A phone asks a server: client and server.
• That server asks a database: client and server again.
• A browser holds a line open, and the server speaks into it: still client first.
• The server goes silent, and only the asking side survives on whatever it saved.

Once you see conversations instead of machines, every system diagram in the world becomes easy to read. It is just arrows of asking and answering.

This concludes Episode #3 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 #4 is "HTTP Explained From Scratch". The language every ask and answer is written in. We will read raw requests line by line, and you will never look at a URL the same way again.

Before you go. here are 5 questions to sit with. Try answering them in the comments; Episode #4 answers all five:

1. You have seen http:// and https:// at the start of URLs. What do those letters actually stand for, and what is the 1 letter difference doing?
2. When a form asks for your password, why is it sent with POST and not GET? What would go wrong with GET?
3. If you refresh a page 5 times, is that 5 identical requests? Does the server know it is you all 5 times?
4. What is inside a URL like dev.to/search?q=backend&page=2 after the question mark? Who reads that part?
5. HTTP is called "stateless." The server forgets you after every single request. Then how does any website keep you logged in?

Think you know some of these? Drop your answers below. I'll tell you if you're right in Episode #4, 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 🕸️