DEV Community: Kush

Backend Odyssey - Ep 03: Client vs server

Kush — Wed, 12 Aug 2026 17:03:12 +0000

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":

Your browser sends it to the server (a normal request, you asked first).
The server looks at its list of open lines and sees your friend holding one.
The server speaks into that open line: "he typed k."
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:

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?
When a form asks for your password, why is it sent with POST and not GET? What would go wrong with GET?
If you refresh a page 5 times, is that 5 identical requests? Does the server know it is you all 5 times?
What is inside a URL like dev.to/search?q=backend&page=2 after the question mark? Who reads that part?
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 🕸️

Backend Odyssey - Ep 02: What Is a Backend? And Why Do We Need One? ⚫

Kush — Mon, 10 Aug 2026 06:57:37 +0000

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 🕸️

Backend Odyssey — Ep 01: What Actually Happens When You Open a Website?

Kush — Sun, 09 Aug 2026 14:13:39 +0000

You type dev.to, press Enter, and about 200 milliseconds later a full page appears on your screen.

It feels like magic. But it is not magic — it is a chain of small, simple steps.

Your request travels across cities. It gets translated into different languages that machines speak. It gets locked inside an envelope, wakes up a computer far away, asks a database a question, and comes all the way back — as the pixels you are looking at right now.

This is Episode #1 of Backend Odyssey, a series where we start from the very beginning and slowly explore what really happens behind the scenes when you use the internet.

Today we answer the most famous question in all of backend engineering — the same one interviewers love to ask:

"What happens when you type a URL and press Enter?"

Let's follow one request on its full journey.

👜 Step 0 — The Browser Checks Its Pockets First

Before touching the network, the browser asks itself one question:

"Have I been here recently?"

Think about how you visit a friend. You don't look up their address every single time — you remember it after the first visit.

The browser does the same. It keeps small notes from past visits:

Browser cache — "Do I already have a copy of this page saved?"
DNS cache — "Do I already know this website's address?"

If the answer is yes, whole steps of the journey get skipped.

This is exactly why the second visit to any website feels much faster than the first.

Keep this idea in your head: never repeat work you have already done.

It is one of the most important ideas in backend engineering. We will meet it again and again — in Redis, in CDNs, in every caching system ever built.

But today the pockets are empty. Time to find the address.

📞 Step 1 — DNS: The Internet's Phonebook

Here is a surprising truth: the internet has no idea what "dev.to" means.

Computers do not find each other using names. They find each other using IP addresses — numbers like 151.101.2.217.

Names exist only for us humans, because nobody wants to remember numbers.

So the very first job is translation: turn the name into a number.

Think of calling a friend. You know their name, but your phone needs their number to place the call. The thing that converts name → number is your contacts list.

The internet's contacts list is called DNS — the Domain Name System.

It is a giant phonebook, spread across the whole world, that no single company owns.

When your browser doesn't know the number, a chain of questions begins:

1. Ask the Resolver

Your computer asks a resolver — usually run by your internet provider, or a public one like Google's 8.8.8.8.

The resolver is like a helpful librarian. It does all the searching for you.

2. Ask the Root Server

The resolver asks a root server: "Who handles .to websites?"

The root server doesn't know dev.to. But it knows who to ask next.

3. Ask the TLD Server

The TLD server — the boss of all .to domains — says: "Ask dev.to's own nameserver."

4. Ask the Authoritative Nameserver

The one server that truly knows, finally answers:

"dev.to lives at 151.101.2.217."

Notice the pattern. Nobody knows the full answer — but everybody knows who to ask next.

Just like asking for directions in a new city: "I don't know that shop, but go ask at the market."

And here is the clever part: the answer gets cached at every layer — your browser, your operating system, the resolver — with an expiry time called a TTL (time to live).

For the next few minutes, nobody in this chain needs to ask again.

Try it yourself right now:

dig dev.to

# the interesting part of the output:
# ;; ANSWER SECTION:
# dev.to.    300    IN    A    151.101.2.217

That 300 is the TTL, in seconds. For 5 minutes, this answer is remembered everywhere.

💡 Backend engineer's takeaway: this is why changing your server's IP in production is never instant. Old cached answers around the world expire on their schedule — not yours.

🤝 Step 2 — TCP: Agreeing to Talk Before Talking

Good — we have the number. Can we just start sending data now?

Not yet.

The internet is an unreliable place. Packets of data get lost, arrive twice, or arrive in the wrong order — all the time.

Before sending anything important, both sides need to be sure the other one is actually listening.

Think of a phone call. You don't start speaking the moment you dial. First:

You: "Hello?"
Friend: "Hello! Yes, I can hear you."
You: "Great, I can hear you too."

Only then does the real conversation begin.

Computers do exactly this. It is called the TCP 3-way handshake:

1. SYN — your browser says: "Hey, can we talk?"

2. SYN-ACK — the server replies: "Yes! I hear you. Can you hear me?"

3. ACK — your browser confirms: "Loud and clear. Let's go."

TCP also numbers every piece of data it sends — like numbering the pages of a letter.

If page 3 goes missing in the post, the receiver notices the gap and asks for page 3 again. That is how TCP guarantees everything arrives, complete and in order.

One important detail: this hello-hello costs one full round trip before any real data moves.

If the server is 150ms away, you pay 150ms just to say hello.

Distance costs time on the internet. This is why companies place servers close to users — that's what a CDN is. Latency is not a software bug. It is physics.

One more small thing: your browser connects to a specific port on that machine — port 443 for secure websites.

Think of the IP address as a building, and ports as its doors. One building, many doors, each for a different purpose.

✉️ Step 3 — HTTPS: Sealing the Envelope

Before the real conversation starts on port 443, one more handshake happens — the TLS handshake.

Two things get done here:

1. Identity check — the server shows its certificate. Think of it as an ID card that proves "I really am dev.to, not an impostor."

2. Secret code — both sides agree on encryption keys. From this moment, everything they exchange is scrambled.

Sending data without TLS is like sending a postcard — anyone who handles it on the way (the coffee shop Wi-Fi, your internet provider) can read it.

With TLS, it becomes a sealed, locked envelope. People can see that a letter is travelling. Nobody can read what is inside.

That is the entire meaning of the padlock 🔒 in your address bar:

Identity verified. Envelope sealed.

💬 Step 4 — HTTP: Finally Asking the Actual Question

The line is open and secure. Now the browser can finally ask for what it wanted all along.

And here is the beautiful part — an HTTP request is just plain, readable text:

GET / HTTP/1.1
Host: dev.to
User-Agent: Mozilla/5.0 ...
Accept: text/html
Cookie: remember_token=abc123

Read it like a sentence:

"GET* me the page at /. I speak HTTP version 1.1. I'm looking for the website called dev.to. Here is my browser's name — and here is a cookie so you remember who I am."*

That's it.

The protocol that runs the entire web is text a human can read. No secret binary language. No magic.

(Methods like GET and POST, headers, cookies — each gets its own episode very soon.)

🍳 Step 5 — The Server: Where the Backend Begins

Everything until now was just delivery — like a letter travelling through the postal system.

This step is where someone actually opens the letter and does the work.

This is the backend. And it is what this entire series is about.

Let's use a restaurant analogy. Your HTTP request is the food order. Here is what happens in the kitchen:

the order arrives
   → middleware checks it     (real customer? allowed in? note it in the logbook)
   → the router reads it      "GET /  →  send this to the HomeController"
   → business logic runs      "this user needs their article feed"
   → the database is asked    SELECT ... FROM articles ORDER BY ... LIMIT 30
   → the response is cooked   raw data becomes HTML (or JSON)

Two things here are worth pausing on.

1. The database is a separate conversation.

Your server doesn't contain the data inside itself. It turns around and asks another machine — the database — in its own language (SQL).

The waiter takes your order. But the kitchen actually makes the food.

Backends are chains of question-and-answer, all the way down.

2. The server trusts nothing.

That cookie could be fake. The input could be malicious.

The server checks everything itself, because it is the last line of defense.

And this is the real answer to "why do we even need a backend?" — which is exactly where Episode #2 begins.

🏠 Step 6 — The Response Comes Home

The kitchen is done. The server sends back another plain-text message — and this one starts with a status code:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: session=xyz789; HttpOnly; Secure

<!DOCTYPE html>
<html>
  ...

200 OK means "everything went well, here is your page."

It could have been:

404 — "no such page exists"
301 — "this page moved"
500 — "I crashed while cooking your order"

One glance at the number, and the browser knows how the story ended.

The browser reads the HTML and discovers it needs more — stylesheets, scripts, images.

Each one repeats a smaller version of this entire journey. A normal page fires off dozens of these little journeys.

Then the browser arranges everything and paints the pixels.

Total time: about 200 milliseconds. A worldwide phonebook lookup, two handshakes, a sealed envelope, a restaurant kitchen, a database question — and it all just worked.

🧪 Try It Yourself: Watch the Journey Live

Don't take my word for any of this. Open a terminal:

# 1. The phonebook lookup, done by hand
dig dev.to +short

# 2. The physical route your data takes (every line = a real machine)
traceroute dev.to        # on Windows: tracert dev.to

# 3. The ENTIRE journey, with a stopwatch on every step
curl -v -o /dev/null -s -w "\nDNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nFirst byte: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://dev.to

That last command prints the time taken by every single step from this article.

Run it twice — you will see the DNS step become nearly zero on the second run. That's caching, live, on your own machine.

You can also open DevTools → Network tab, refresh any page, and click the first request. The "Timing" panel there is literally this blog post, measured.

🎯 What Interviewers Ask About This

This exact topic, as it appears in real interviews:

1. "Walk me through what happens when you type google.com."

The classic. A strong answer covers, in order: cache checks → DNS → TCP handshake → TLS → HTTP request → server work → response → rendering.

2. "Why is the first visit to a website slower than the second?"

Caching at many layers — DNS cache, browser cache, and reused connections.

3. "What's the difference between an IP address and a domain name?"

Names are for humans. DNS translates them into the numbers machines route with.

4. "Why does latency matter even when internet speed is high?"

Handshakes cost full round trips before any data flows. Distance is paid in round trips, not in megabits.

🌱 The Key Idea Behind It All

The internet is not one big system. It is many small, simple systems — each doing one job, each handing off to the next.

The browser remembers (caching)
DNS translates (names → numbers)
TCP guarantees (reliable delivery)
TLS protects (sealed envelopes)
HTTP asks (readable questions)
The server thinks (the backend)
The database remembers everything (the source of truth)

Every box in the first diagram becomes its own deep-dive episode in this series.

This concludes Episode #1 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 #2 is "What Is a Backend? And Why Do We Need One?" — we zoom into Step 5 of today's journey and draw the exact line between client and server.

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

Browsers today can run full 3D games and edit videos. So why can't the browser just be the whole app — why does a server need to exist at all?
When you check your Instagram feed, where does that data actually live — on your phone, or somewhere else? And why there?
If I open my browser's DevTools, I can edit any website's code live on my screen. Why doesn't that let me change my bank balance?
Two users open the same website at the same moment and see completely different content. Same URL, same server — how?
Frontend validation already checks that your email format is correct before submitting. Why does the server check it again?

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