A team serves photos through an image CDN using URLs like /photos/hero.jpg?width=640&format=auto. What does the image CDN actually do with that request, and where does the original file live?
answer
- one master, many derived outputs
- the URL carries the instruction
- first request pays, rest are cached
- origin holds the original file
basics
~20 sAn image CDN keeps one high-resolution master at an origin and derives every variant at request time: it reads the transformation parameters from the URL, resizes and re-encodes the master, returns that derivative, and caches it at the edge for later requests.
solid answer
~50 sThe team uploads or stores **one master image** — the largest, highest-quality version — at an origin the CDN can read (object storage, the app's own server, or the CDN's own media library). The URL that the page requests is not a file on disk; it is an **instruction**. When a browser asks for `/photos/hero.jpg?width=640&format=auto`, the edge first looks for a cached derivative matching that exact request. On a miss it fetches the master from the origin, resizes it to 640px, encodes it in whatever format the requesting browser accepts, returns it, and stores the result at the edge. Every later request for the same URL is a plain cache hit, so the transform cost is paid once per derivative per edge, not once per visitor. The practical win is that adding a new size or switching formats is a URL change, not a re-export and redeploy of the asset pipeline.
go deeper
Be able to say plainly that the URL parameters ask for a transformation, that one original lives at the origin, and that the CDN caches the result it produces.
Explain the miss path in order — cache lookup, origin fetch, decode, resize, encode, store — and why the first request for a variant is measurably slower than the rest.
Show that you have operated one: talk about cold-derivative latency on the hero image, purge strategy when a master changes, and monitoring miss rate rather than trusting a warm test.
Own the dependency question — metered transformations, vendor-specific URL dialects leaking into templates, and what your fallback is if the image provider is unavailable or has to be swapped.
## The problem an image CDN solves A site that wants correctly-sized, modern-format images needs many versions of every photo: several widths for different layouts and screen densities, and more than one encoding so newer browsers get a smaller file. Producing that matrix by hand — exporting variants in a design tool and committing them — does not scale. Twenty photos times five widths times three formats is three hundred files that must be regenerated whenever the design changes, the crop changes, or a new format becomes worth serving. An image CDN removes the matrix from the repository. The team keeps exactly one **master**: the largest, least-compressed version of each image. Everything else is derived on demand. ## The URL is an instruction, not a file The defining feature is that transformation intent is encoded in the request itself, usually as query parameters: ``` https://images.example.com/photos/hero.jpg?width=640&format=auto&quality=75 ``` The exact parameter names differ per vendor — `w` versus `width`, `fm` versus `format` — which matters when you migrate, but the shape is the same everywhere: a path that identifies the master, plus parameters that describe the wanted output. Nothing named `hero-640.avif` exists in storage. The 640px AVIF is *produced* the first time somebody asks for it. ## What happens on a request 1. The browser requests the URL and it lands at the nearest CDN edge. 2. The edge computes a cache key from the request — normally the path plus the transformation parameters, and often something about which formats the client accepts. 3. **Cache hit:** the stored derivative is returned immediately. This is the common case and it costs roughly what any static file costs. 4. **Cache miss:** the edge (or a regional transform tier behind it) fetches the master from the origin, decodes it, applies the requested resize/crop/quality, encodes the output, returns it, and stores it under that cache key. Step 4 is expensive relative to step 3 — an origin round trip plus decode and re-encode of a large image. That is why the first visitor to hit a novel derivative sees noticeably worse timing than everyone after them, and why an image on a rarely-visited page can be perpetually cold if derivatives expire before the next visitor arrives. ## Two caches, not one There are at least two layers in play and they are worth keeping distinct. The **derivative cache** is the CDN's own store of transformed outputs, keyed by the transformation. The **browser cache** stores whatever bytes that visitor received, keyed by URL. A derivative can be warm at the edge and still be a full download for a first-time visitor; conversely a repeat visitor can skip the network entirely while the edge derivative has long since expired. ## What lives where - **Master image:** origin storage (a bucket, the CMS, or the vendor's media library). Ideally uploaded once, never edited in place — an in-place edit under the same path is invisible to a cache that already holds derivatives of the old bytes. - **Derivatives:** the CDN's cache, ephemeral by design and re-creatable at any time. - **The decision about which URL to request:** the page. The CDN can only serve what it is asked for; a page that requests a 2000px-wide derivative for a 400px slot gets exactly the oversized file it asked for, quickly. ## Where teams get it wrong The most common misunderstanding is treating the CDN as a magic optimizer — "we put images behind a CDN, so images are handled." It is not. It is a *generator plus cache*. If the page requests the wrong size, the CDN faithfully generates the wrong size. If the URL parameters change on every render, the CDN faithfully generates a fresh derivative every time and the cache never helps. The second is forgetting the cold path exists at all. Load-testing a warm cache tells you very little; the number that matters for a first deploy, a new campaign page, or a long-tail catalogue is what a *miss* costs. The third is assuming derivatives are free. Vendors typically bill for transformations and for storage of unique derivatives, so an unbounded set of requested variants is both a performance problem and an invoice problem.
- If you edit a master image in place at the same path, why might visitors keep seeing the old picture?Because caches key on the URL, not the bytes behind it. Derivatives already stored at the edge — and copies already in browser caches — still match that URL and are served until they expire or are purged. The usual fixes are to publish masters under content-addressed or versioned paths so a new image gets a new URL, or to issue an explicit purge for the old one after replacing it.
- Why can a page still be slow even though every image is served by an image CDN?Because the CDN only produces the bytes it is asked for. If the markup requests a far larger derivative than the layout slot needs, the download is still oversized. If the important image is discovered late in the document, it is still requested late. And on a cold derivative the first visitor pays an origin fetch plus a re-encode before a single byte arrives.
- What is the practical cost of an image CDN compared with committing pre-generated files?You take on a runtime dependency and a usage bill: transformations and unique derivatives are metered, an outage or misconfiguration at the vendor takes your images down, and vendor-specific URL syntax spreads through your templates. Teams manage that by generating image URLs through one small helper module so the parameter dialect lives in a single place.
saying these in an interview costs you the question
- Thinks the CDN stores every size as a real file
- Says an image CDN automatically makes images fast
- Assumes transformation happens on every request, never cached
- Believes replacing the master instantly updates what visitors see