CDN caching for static and dynamic content
CDN cache behavior and invalidation.
cache static assets with long TTLs and versioned filenames; bypass or short-cache dynamic per-user responses; invalidate via fingerprinted URLs not purges.
What's really being asked
The question checks that you can configure caching differently per content type and that you understand fingerprinting as the robust answer to static asset invalidation rather than relying on purges.
The full answer
Static assets are immutable per version and identical for every user, so cache them aggressively at the edge with long TTLs, set Cache-Control max-age high, and enable compression. Dynamic, user-specific API responses must not be cached as shared content; either bypass the cache for those paths or cache only very short-lived, non-personalized responses, and use the Vary header and authentication-aware rules so one user never receives another user's cached data. Many CDNs can still accelerate dynamic traffic by terminating TLS at the edge and reusing warm origin connections even when the response itself is not cached. For invalidation of an updated static asset, the durable pattern is cache busting through fingerprinted filenames: embed a content hash like app.9f3a2b.css so a change produces a new URL that the edge has never seen, sidestepping stale caches entirely. Explicit cache purge exists but is slower, propagates globally with delay, and should be a fallback, not the routine mechanism.
The mistakes people make
Caching user-specific API responses without honoring Vary or auth, leaking data between users. Relying solely on manual purges for every deploy. Applying one TTL policy to all content regardless of type.
What usually comes next
How do Cache-Control and Vary headers interact? What is stale-while-revalidate? How does the CDN handle cache keys for query strings?
A concrete example
CSS is served as styles.7c21.css with a one-year max-age and immutable flag, so a redeploy emits a new hash and the old file is never re-fetched. The /api/account path is set to bypass cache so each user always gets their own fresh data.
Interview question
What is the most reliable way to ensure users receive an updated CSS file without serving stale edge copies?
- a.Set the asset TTL to zero so the CDN re-fetches it on every request
- b.Issue a global cache purge after every deploy and wait for propagation
- c.Add the user ID to the cache key for all static assets
- d.Use a content-hashed filename so the updated asset has a brand-new URLCorrect
Why? this is the answer
A content hash changes the URL on every update, so the edge treats it as new and never serves a stale copy. Global purges are slow and propagate unevenly, and a zero TTL defeats CDN caching entirely.
Just read this? Test yourself on what you have been reading.
Read the original → learn.microsoft.com
- #cdn
- #caching
- #performance
- #invalidation
- #cloud
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles