Chapter 2 – Interview Questions: How the Internet Works

Alright, so this is one of those questions where you can go as deep as you want. I'd walk through it layer by layer. First, the browser checks its local cache — do I already have an IP for google.com? If not, it kicks off a DNS lookup, which might hit the OS cache, then the router, then your ISP's recursive resolver, and potentially all the way up to the root nameservers.

Once we have the IP, the browser opens a TCP connection — that's the three-way handshake: SYN, SYN-ACK, ACK. Since it's HTTPS, we then do a TLS handshake on top of that — negotiate cipher suites, verify the certificate, establish session keys. Only then does the browser send the actual HTTP GET request.

The server processes it, sends back HTML, and the browser starts parsing. As it hits CSS and JS references, it fires off more requests. The browser builds the DOM, applies styles (CSSOM), runs JavaScript, and paints pixels. Honestly, the whole thing takes maybe 200-500ms but there's an incredible amount happening under the hood.

Follow-ups: Where would you add caching to speed this up? What changes if the user is on a mobile network?

So basically, TCP gives you reliability — guaranteed delivery, ordering, congestion control — but you pay for it with latency and overhead. UDP is the opposite: fire and forget, no guarantees, but it's fast.

I'd pick UDP when the data is time-sensitive and a dropped packet is better than a late packet. Video streaming, online gaming, VoIP — in those scenarios, if a video frame arrives late, it's useless anyway. You'd rather skip it and show the next one. DNS also uses UDP because the queries are tiny and you can just retry if one gets lost — way faster than setting up a whole TCP connection for a single question-and-answer.

The way I think about it is: if your application can tolerate some data loss but can't tolerate latency, UDP is your friend. If every byte matters and order matters, stick with TCP.

Follow-ups: How does QUIC relate to this? When might you build your own reliability layer on top of UDP?

DNS is one of those things people forget about until it breaks — and when it breaks, everything breaks. If your DNS provider goes down, nobody can resolve your domain, and your entire service is effectively offline even if your servers are perfectly healthy.

The way I'd mitigate this: first, use multiple DNS providers. Second, set appropriate TTLs — too low and you're hammering DNS on every request, too high and you can't fail over quickly. I'd typically go with something like 60-300 seconds for services that need fast failover. Third, I'd make sure internal service-to-service communication doesn't rely on external DNS — use service discovery or internal DNS that you control.

Honestly, I've seen a major outage caused by a single DNS misconfiguration. It's taught me to treat DNS as critical infrastructure, not an afterthought.

Follow-ups: How would you handle a DNS propagation delay during a migration? What's your approach to DNS-based load balancing?

HTTPS is basically HTTP with a security layer — TLS — wrapped around it. The way I think about it is: it solves three problems. First, encryption — nobody between you and the server can read the data. Second, authentication — you can verify you're actually talking to google.com and not some impersonator. Third, integrity — nobody can tamper with the data in transit without you knowing.

The TLS handshake is where the magic happens. The server presents its certificate, the client verifies it against trusted certificate authorities, they agree on a cipher suite, and then they use asymmetric crypto to exchange a symmetric session key. After that, all communication is encrypted with that fast symmetric key. So you get the trust of public-key crypto for the setup, and the speed of symmetric crypto for the actual data transfer.

Follow-ups: What's the performance cost of HTTPS? How does certificate pinning work and when would you use it?

I'd attack this from multiple angles, working from the user towards the server. First, reduce round trips — use HTTP/2 or HTTP/3 so you're multiplexing requests over a single connection instead of opening new ones. Enable connection keep-alive. Use a CDN to get your content physically closer to users.

Second, caching at every layer — browser cache, CDN cache, application cache, database query cache. The fastest request is one you never make. Third, on the server side — optimize database queries, use connection pooling, consider async processing for anything that doesn't need to be in the critical path. Fourth, reduce payload size — compress responses with gzip or brotli, optimize images, lazy-load what's below the fold.

Honestly, before optimizing anything, I'd measure first. Use something like a waterfall chart to see where the actual bottleneck is. No point optimizing DNS resolution if your database query takes 3 seconds.

Follow-ups: How do you decide what to cache vs. what must be fresh? What tools do you use to profile latency in production?