A site starts serving through a CDN. Explain the mechanism by which answering from an edge location near the user makes a request faster, and name one kind of request a CDN cannot speed up much.
answer
- latency, not file size
- round trips before the first byte
- handshakes terminate at a nearby PoP
- only cacheable responses get the big win
- bytes arrive sooner, not cheaper
basics
~20 sA CDN keeps copies of responses in data centres near users, so each request travels a short distance instead of crossing an ocean, removing most of the round trips before the first byte. It only helps responses it can cache; an uncacheable, per-user response still goes to the origin.
solid answer
~50 sA CDN is a fleet of caching servers spread across many cities, and the site's hostname resolves to a nearby one instead of to the origin. The win is latency: an HTTPS request needs several sequential round trips — TCP handshake, TLS handshake, then the request itself — before any content moves, so an intercontinental path at roughly 90 ms per round trip costs a few hundred milliseconds of pure setup, while a nearby edge costs tens. On a cache hit the whole exchange stays local. On a miss the edge still terminates the connection nearby but must fetch from the origin, so the gain is much smaller. What a CDN cannot fix is an uncacheable response — personalized HTML, an authenticated API call — where the origin's own work still happens, and it does nothing about the cost of parsing and executing the bytes once they arrive.
code
bash · 3 linescurl -s -o /dev/null \
-w 'tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n' \
https://example.com/app.jsgo deeper
Be ready to say plainly that a CDN stores copies close to users and that the saving is travel time on multiple round trips, and to name one thing it cannot help — an uncacheable per-user response.
Explain the mechanics: the round trips of TCP and TLS setup that now terminate at the edge, what changes on a hit versus a miss, and why the origin's own processing time is untouched on a miss.
Show you check before you credit the CDN: separate connection time from time to first byte, distinguish a delivery problem from a client-side processing problem, and say when adding a CDN is simply the wrong fix.
Frame it as where you spend the latency budget across the whole path — edge coverage and cacheability versus origin speed versus payload cost — and be able to say which of those actually limits your product's users today.
## What a CDN actually is A content delivery network is a fleet of caching HTTP servers placed in data centres around the world. A single site is usually grouped into *points of presence* (PoPs) — one PoP per city or region. You point the hostname at the CDN, and its routing layer (anycast addressing, or latency-based DNS) steers each user to a nearby PoP. That edge server either answers from its own cache or fetches the response from your origin server, stores a copy, and answers. So the CDN does not make your server faster. It moves *where the conversation happens*. ## Why distance is the cost being removed Light in fibre travels at about two-thirds of its vacuum speed, and real network paths are not straight lines, so intercontinental round-trip times typically land somewhere between 70 ms and 250 ms, while a request to a PoP in the same metro area is often under 10 ms. For small files, latency dominates — not bandwidth — because an HTTPS request needs several *sequential* round trips before the first content byte appears: - DNS resolution (often already cached) - the TCP handshake — one round trip - the TLS handshake — one round trip with TLS 1.3, two with TLS 1.2 - the HTTP request travelling out and the first response byte coming back — one more round trip Call it three round trips of setup for a fresh connection. At 90 ms per round trip that is roughly 270 ms before a byte of a 4 KB stylesheet appears; at 8 ms it is around 25 ms. Nothing about the file changed. You changed how far the conversation has to travel — and how many times. ## Hit versus miss On a **cache hit**, the request never leaves the region: the handshake, the request and the response all happen against the nearby edge server. On a **cache miss**, the user still gets the local handshake, but the edge now has to go and get the response from your origin. Edges usually keep warm, already-established connections to the origin, so they skip most of the setup a cold client would pay — but the origin round trip and the origin's own processing time are still in the user's critical path. A miss is normally a little better than having no CDN, and nowhere near as good as a hit. That is exactly why cache hit ratio is the number CDN work is judged on. ## What a CDN cannot speed up - **Uncacheable responses.** A personalized HTML document, an authenticated API response, or anything sent with `Cache-Control: no-store` has to reach the origin every time. Only the connection setup moves closer; the origin's thinking time is untouched. - **A slow origin.** If the server needs 600 ms to render a page, a CDN in front of it does not hide that on a miss. - **Everything after the bytes arrive.** Parsing and executing a large JavaScript bundle, blocking stylesheets, a hero image the browser discovers late — a CDN delivers bytes sooner, it does not make them cheaper to process. Teams who "added a CDN" and saw their headline metrics barely move usually have a main-thread or resource-discovery problem, not a distance problem. - **The first request for each object at each PoP.** Caches are populated by traffic; the first visitor to a given PoP pays for a miss. ## Confirming it rather than assuming it A timing breakdown separates the parts: ```bash curl -s -o /dev/null \ -w 'tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n' \ https://example.com/app.js ``` If `tls` is small but `ttfb` is much larger, the time is going into the origin fetch, not the distance — which means you are looking at a cache miss or an uncacheable response, not a routing problem. Most CDNs also report cache status in a response header, though the header name is a per-provider convention rather than a standard. ## The interview point Say the mechanism (round trips removed because the endpoint is nearby), state the precondition (the response has to be cacheable for the big win), and name the limit (bytes arrive sooner; they do not become cheaper to process). Answering "a CDN makes the site faster" with no mechanism is the weak version of this answer.
- If the edge has to fetch from the origin anyway, why is a cache miss through a CDN usually still no worse than going direct?The user's expensive part — DNS, TCP and TLS setup — completes against the nearby edge, and the edge typically already holds a warm connection to the origin over a well-provisioned path. So the user pays local setup plus one origin fetch, instead of full setup plus the fetch across the same distance. It is a smaller win than a hit, not a regression.
- A team moves their images to a CDN and their largest image still paints late. What would you check?Whether delivery was ever the bottleneck. Check when the browser starts the request at all, and how long the transfer itself takes versus how long the request sat waiting. If the byte transfer is short but the request begins late, the problem is discovery or contention on the client, and no amount of edge proximity changes it.
- Does a CDN help more on a fast fibre connection or a high-latency mobile network?Relatively more on the high-latency network. The CDN's saving is measured in round trips, so the worse each round trip is, the larger the absolute saving from removing several of them. On a low-latency connection the same three saved round trips may be worth a few milliseconds.
A CDN is a local branch library rather than a national archive: most requests are satisfied down the road, and only the rare book nobody stocks locally still triggers a trip to the central building.
saying these in an interview costs you the question
- A CDN makes every request on the page faster
- Assuming the CDN speeds up JavaScript execution
- Thinking a CDN fixes a slow origin on cache misses
- Believing a CDN is about bandwidth rather than latency
- Assuming the CDN caches everything automatically