Q227: HTTP Caching, CDN and Immutable Assets

What Interviewers Want To Evaluate

Interviewers want to know whether you can design cache behavior that improves repeat performance without serving stale or unsafe data.

They check HTTP caching headers, CDN behavior, immutable assets, revalidation, cache busting, HTML caching, API caching, private data, stale-while-revalidate, and deployment implications.

Short Interview Answer

Hashed static assets should usually be cached for a long time with immutable caching because a filename change represents a content change. HTML and personalized API responses need more careful caching because they may change frequently or contain user-specific data. I separate immutable static assets, public shared data, and private user data, then choose cache-control rules and CDN behavior based on freshness and safety requirements.

Detailed Interview Answer

Caching is one of the highest leverage performance tools.

It can also create subtle correctness bugs.

A good cache strategy answers:

who can cache this
how long can it be reused
how is it invalidated
is it user-specific
can stale content be acceptable
does the URL change when content changes

Static Hashed Assets

Modern builds often create hashed files.

Example:

app.8f31c2.js
styles.a91d0.css
hero.77ab2.webp

If the content changes, the filename changes.

That enables long-lived caching.

Cache-Control: public, max-age=31536000, immutable

This is safe because a new deployment references a new URL.

HTML Is Different

HTML usually should not be cached like hashed assets.

Reasons:

it references current asset hashes
it may include metadata
it may change after deploy
it may include personalized shell decisions

If HTML is cached too aggressively, users may receive an old shell pointing to outdated behavior.

Frameworks and hosting platforms often manage this for you.

Understand the policy rather than overriding blindly.

Public vs Private Data

Public shared data can be cached by CDNs.

Examples:

public docs
marketing content
public handbook chapters
shared configuration
static topic metadata

Private data should not be cached publicly.

Examples:

user profile
personal progress
permissions
billing data
private documents

Use private or no-store policies when data is user-specific.

Cache-Control Basics

Common directives:

public
private
max-age
s-maxage
no-cache
no-store
immutable
stale-while-revalidate

Important distinction:

no-cache means can store but must revalidate before reuse
no-store means do not store

This distinction comes up often in interviews.

CDN Cache

CDNs cache near users.

They improve:

latency
bandwidth
origin load
global consistency for static content

But CDN cache needs invalidation strategy.

Options:

content-hashed URLs
short TTL
purge by tag
manual purge
stale-while-revalidate
versioned endpoints

Content-hashed URLs are the cleanest for static assets.

stale-while-revalidate

stale-while-revalidate allows serving cached content while refreshing in the background.

This can improve perceived performance.

It is appropriate when slightly stale data is acceptable.

Examples:

public documentation index
topic metadata
non-critical public recommendations

Avoid it for:

auth state
permissions
checkout totals
security-sensitive data

API Caching

API responses need data classification.

public and stable: CDN cache
public but changing: short TTL or SWR
private user data: private or no-store
mutation response: usually no-store

Do not accidentally cache authenticated responses publicly.

Cache keys must include all factors that change the response.

Cache Busting

Cache busting should be automatic.

Good:

hashed filenames
versioned URLs
deployment-specific asset paths

Weak:

manual query strings without policy
clearing all CDN cache for every deploy
random cache-control changes

Strong cache strategy reduces operational drama.

Debugging Cache Issues

Inspect:

Cache-Control
ETag
Age
CDN cache status
Last-Modified
Vary
request headers
response headers

The Vary header matters.

If content varies by language, encoding, auth, or device, the cache must know.

Common Mistakes

Common mistakes include:

caching HTML like immutable assets
publicly caching private API responses
forgetting Vary headers
using no-cache when no-store is required
not using content hashes for long-lived assets
purging CDN manually for every small change

Caching bugs can be both performance and security issues.

Senior Trade-Offs

Cache strategy balances:

freshness
performance
safety
operational complexity
origin cost
global consistency

The best answer classifies data before choosing headers.

Interview Framing

In an interview, say:

I classify resources first. Hashed static assets get long immutable caching, public shared data may use CDN caching or stale-while-revalidate, and private user-specific data avoids public caches.

Revision Notes

• Hashed assets are good candidates for immutable caching.
• HTML needs more careful freshness.
• Private data must not be cached publicly.
• no-cache and no-store are different.
• CDN caching needs invalidation and key strategy.
• Vary affects cache correctness.

Follow-Up Questions

• Why can hashed assets be cached for a year?
• What is the difference between no-cache and no-store?
• When is stale-while-revalidate appropriate?
• Why is caching authenticated API data risky?
• How would you debug a stale CDN response?

How I Would Answer This In A Real Interview

I would explain that caching starts with resource classification. Static hashed assets can be cached almost indefinitely because new content gets a new URL. HTML and APIs need more careful policies based on freshness and privacy. Public shared data may use CDN caching or stale-while-revalidate, while private data should be private or no-store. I would inspect headers like Cache-Control, Age, ETag, Vary, and CDN cache status when debugging.