What DNS actually does on every request Every request to example.com starts with a lookup that has nothing to do with your application: something has to turn that name into an IP address before a single TCP packet leaves the machine. That translation is DNS, the Domain Name System, and it runs on every request, whether the client is a browser, curl, or a backend service calling another backend by hostname. ...
What TLS actually protects on an HTTPS connection Load a page over plain http:// on a network you don’t control, an airport or a coffee-shop router, and everything you send travels as readable text. The URL path, the cookies, the form fields, the password in a login POST: anyone on that network with a packet sniffer reads it as it goes past. TLS, Transport Layer Security, is the protocol that stops that. It sits between TCP and the application protocol, so by the time HTTP starts talking, the connection is already encrypted and tied to a verified server identity. HTTPS is HTTP run over that connection instead of a plain one. ...
What a CDN actually does to a request A user in Tokyo loading a page hosted on a server in Virginia pays for that distance twice: once for the request to arrive, once for the response to come back. Fiber runs at a fixed fraction of the speed of light, and that trip alone costs on the order of 150-200ms round-trip before the origin has done any work. Add a database query and a slow hop or two, and a page that feels instant next door feels sluggish on the other side of the planet. ...
What sits between a browser and your app Point a browser at example.com and the request never touches the process running your code. It hits something else first: a server that reads the request, decides which backend should answer, forwards it there, and sends the response back as if it had produced that response itself. That server is a reverse proxy. Nginx, Caddy, Traefik and HAProxy all do this job, and so does the load balancer sitting in front of a Kubernetes cluster. The arrangement never changes: clients talk to the proxy and to nothing else. The real servers stay behind it, however many there are and wherever they run. ...
Why two containers on the same host can’t reach each other by default Start Postgres and your API with plain docker run and the API cannot reach the database, even though both containers sit on the same machine. 1 2 docker run -d --name db postgres:16 docker run -d --name api myapp Both land on Docker’s default bridge network, where every Docker container goes unless you say otherwise. They get IP addresses. What they don’t get is any way to find each other by name, so the API would have to hardcode the database’s internal IP — an address that changes every time the container restarts. ...