01 — Internet Fundamentals for the Backend — The Same Stack, Viewed From the Other End

I first learned the internet stack — browser, HTTP, DNS, the network below — as a frontend concern. Re-reading it a second time with the server in mind collapsed it into a simpler frame: the backend lives at the exact same layers, but its job is to answer, not to ask. [1] Everything a client does as a request, a server does as a response, over the same conversation.

The shift that mattered for me was directional. The frontend initiates; the backend listens. A browser types a domain, resolves it, opens a connection, and sends a request. The server's whole existence is sitting on a port, accepting that connection, and producing a response. Once I could see that the server is just the other endpoint of one shared stack, most of "backend" stopped feeling like a separate world.

HTTP: the conversation the backend answers

The conversation is HTTP — a stateless, line-by-line protocol of requests and responses [3]. The frontend vocabulary (methods, status codes, headers) is the same vocabulary the backend speaks back. The difference is who's producing each part:

• A request arrives carrying a method (GET, POST, PUT, DELETE) and a path. The backend's job is to decide what to do with that verb-noun pair.
• A response leaves carrying a status code (200 ok, 404 not found, 500 server error) and a body. That code is the backend's first and most honest signal to the client.

Statelessness is the detail that shapes backend architecture more than any other. Because the server remembers nothing between requests, anything that must persist — a login, a cart, a draft — has to be sent back by the client (a token, a cookie) or stored server-side under a key the client carries. Sessions, JWTs, and the whole auth layer exist to fake the memory HTTP refuses to provide.

HTTPS: the same conversation, encrypted

HTTPS is not a different protocol; it's HTTP wrapped in TLS so nobody between client and server can read or alter the exchange [7]. From the backend's side this matters twice over: the server is the side that holds the TLS certificate, and the server is the side that terminates the encryption before handing the plaintext request to the application code. Termination often happens at a reverse proxy (Nginx, a load balancer) rather than in the app process — a separation I'll come back to when I get to web servers.

Hosting: a process on a box, listening on a port

"There is no cloud" is the line that did the most work for me. A backend is an ordinary program running on an ordinary machine in a rack somewhere [4]. The program binds to a port (say :3000), and the machine's operating system forwards incoming connections on that port to the process. Hosting is renting that machine plus its always-on connection to the network.

The flavors of hosting are the same layer, differing only in how much of the box I'm willing to manage:

• Shared / VPS / dedicated — a slice of a real machine, more or less isolated.
• PaaS — I push code, the provider runs the process and binds the port.
• Serverless / edge — I stop thinking about the box entirely; the provider runs my function on machines near each user.

The trade-off is always control versus convenience. A VPS gives me root and a port; serverless gives me a function signature and nothing else.

Naming: domains and DNS, the layer the server hides behind

No client connects to my box by IP — they connect by name. DNS is the distributed phonebook that resolves aveshina.my.id into the number my machine owns, consulted in milliseconds before every connection [5][6]. The lookup fans out through a hierarchy — recursive resolver, root, TLD, then the authoritative nameserver for my domain — and each level is cached so most lookups never make the full trip.

For the backend, the practical consequence is that DNS is the first thing I configure when I deploy. The domain's A (or CNAME) record has to point at my box's IP (or my provider's load balancer) before any traffic can arrive. A misconfigured DNS record is the highest-on-the-stack failure mode: the request never reaches me at all.

dig +short aveshina.my.id

76.76.21.21

A name resolving to a number is the last step before the request becomes my problem. Once that number comes back, the client opens a TCP connection to it, and the bottom layer takes over.

The network: packets, IPs, and one shared agreement

The bottom layer is plumbing — cables (including undersea ones), routers, and TCP/IP, the protocol every network agreed to speak so they could hand data to each other [1][2]. Data moves as packets, small self-addressed units routed independently and reassembled at the destination. Every device has an IP address that routers use to forward packets roughly in the right direction.

The part that clicked for me as a backend author: my process never sees raw packets. The OS's network stack reassembles them, hands my process a continuous byte stream over the socket, and my HTTP library parses that stream into a request object. The layers below the port are someone else's responsibility — the kernel's, the provider's, the internet's. My code starts at "a connection arrived on my port."

How I use this

The payoff is diagnostic, the same as on the frontend — except now I'm debugging from the answering end. When a request fails to reach my server, I walk the stack top-down:

• Does the domain resolve? dig it. If not, DNS.
• Does it resolve to the right IP? Check the A record vs. the box. If not, DNS or the provider's routing.
• Can I reach the port from outside? curl or telnet. If not, firewall, security group, or the process isn't running.
• The request arrived but the response is wrong? Now it's my code — the HTTP layer, the status code, the body.

Naming the layer before reaching for a fix is the whole habit. The backend isn't a separate internet; it's the same stack, viewed from the port that answers.

References

[1] cs.fyi, "How does the Internet work?," 2020. [Online]. Available: https://cs.fyi/guide/how-does-internet-work

[2] "The Internet Explained," Vox, 2014. [Online]. Available: https://www.vox.com/2014/6/16/18076282/the-internet

[3] Cloudflare, "What is HTTP?," 2024. [Online]. Available: https://www.cloudflare.com/en-gb/learning/ddos/glossary/hypertext-transfer-protocol-http/

[4] Mozilla, "What is a web server?," MDN Web Docs. [Online]. Available: https://developer.mozilla.org/en-US/docs/Learn/Common_questions/Web_mechanics/What_is_a_web_server

[5] Cloudflare, "What is DNS?," 2024. [Online]. Available: https://www.cloudflare.com/en-gb/learning/dns/what-is-dns/

[6] "How DNS works," howdns.works. [Online]. Available: https://howdns.works/

[7] "How HTTPS works," howhttps.works. [Online]. Available: https://howhttps.works/