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 🕸️
Top comments (0)