A user in Mumbai types your URL and presses enter. Walk me through every hop until the HTML reaches their browser. Where would you look first if the page were slow?

What the interviewer is testing

This is the classic architecture screening question, and it is asked because the answer's depth correlates strongly with real experience. There is no trick — it is a knowledge audit.

The path

1. DNS resolution. Browser cache, then OS cache, then the configured resolver. On a miss the resolver walks root → TLD → authoritative nameserver. Latency-based or geo routing at the authoritative server may return a different address for Mumbai than for London. Cost: 0 ms cached, 20–120 ms cold.

2. TCP handshake. SYN, SYN-ACK, ACK — one round trip to the nearest CDN edge. If the edge is in Mumbai, roughly 5–20 ms; if the connection goes to an origin in Virginia, 200 ms or more. This is the single biggest argument for edge termination.

3. TLS handshake. TLS 1.3 completes in one round trip; TLS 1.2 needs two. Session resumption or 0-RTT removes it for returning visitors. Certificate chain validation happens here, and OCSP stapling avoids a separate request to the CA.

4. CDN edge. On a hit, the response is served now and everything below is skipped. On a miss, the edge fetches from origin — over a pre-warmed, optimised backbone connection rather than the public internet, which is a large and often-forgotten benefit.

5. Origin load balancer. Health-checked routing to a healthy instance, possibly with a second TLS handshake if traffic is encrypted internally.

6. Reverse proxy / ingress. Path routing, rate limiting, header manipulation.

7. Application. Session lookup, authorisation, business logic.

8. Data layer. Cache lookup, then database on a miss. This is where most of the variable time lives, and where N+1 query patterns hide.

9. Response back. Compression, cache headers that determine whether the next visitor even reaches step 4.

10. Browser rendering. HTML parse, blocking CSS and JS, subresource fetches — which repeat steps 1–4 for every distinct origin, which is why third-party scripts are so expensive.

Where to look first

In this order, because it goes cheapest-diagnosis-first:

1. Is it slow for everyone or just this region? Regional means DNS routing, edge coverage or peering. Global means origin.
2. Is it slow for the first byte or after it? High TTFB means server-side or network; low TTFB with slow render means front-end.
3. Cache hit ratio at the CDN. A ratio that dropped means a cache-busting change, and it is a common and easily-missed cause.
4. Server-side traces. p99 by endpoint, then the slow span within the trace.
5. Database. Slow query log, then connection pool saturation — a request waiting for a connection looks like a slow query but is not one.

What a strong answer adds

Naming the fixed costs that no code change removes: light takes about 60 ms round trip between Mumbai and Virginia, and the only fix is to serve from closer. Candidates who reach for physics before micro-optimisation are the ones who have debugged this before.