Q017: HTTP Caching, Cache-Control, ETag and Revalidation

What Interviewers Want To Evaluate

This question tests whether you understand browser caching beyond "the browser stores files." Interviewers want cache layers, freshness, validation, Cache-Control, ETag, Last-Modified, immutable assets, CDNs, and why caching is both a performance tool and a correctness risk.

For senior roles, the strongest answer separates static assets, HTML, APIs, authenticated responses, and CDN behavior.

Short Interview Answer

HTTP caching lets browsers and intermediaries reuse responses instead of downloading them again. Cache-Control tells caches how long a response is fresh and whether it can be stored. ETag and Last-Modified allow revalidation: the browser asks the server if the cached response is still valid and can receive 304 Not Modified. Hashed static assets can use long cache lifetimes. HTML and dynamic data need shorter or revalidated caching to avoid stale behavior.

Detailed Interview Answer

When a browser receives a response, it looks at caching headers to decide whether it can store and reuse it. If the response is fresh, the browser can use it without contacting the server. If it is stale but revalidatable, the browser can send a conditional request.

Cache-Control: max-age=31536000, immutable is appropriate for fingerprinted files such as app.8df31.js, because the URL changes when the content changes. HTML should usually avoid long immutable caching because the same URL may need to point at new assets after deployment.

The browser cache is only one layer. CDNs, reverse proxies, service workers, framework data caches, and memory caches can also be involved. A senior engineer should know which layer is serving a response before changing headers.

Deep Technical Explanation

Freshness and validation are separate ideas:

fresh response
  -> reuse directly
stale response with validator
  -> ask server with If-None-Match or If-Modified-Since
  -> server returns 304 or new 200 response
stale response without validator
  -> download again

Revalidation saves bandwidth because the body is not downloaded again when the resource has not changed.

Important Cache-Control Directives

max-age defines freshness lifetime in seconds. no-cache means the response may be stored but must be revalidated before reuse. no-store means do not store the response. private limits storage to the browser. public allows shared caches. s-maxage targets shared caches like CDNs.

These names are easy to misunderstand. no-cache does not mean "do not store." It means "store, but revalidate before using."

Code Example

# Hashed static asset
Cache-Control: public, max-age=31536000, immutable
ETag: "asset-v42"

# HTML document
Cache-Control: no-cache
ETag: "html-v18"

# Sensitive account response
Cache-Control: no-store

This split lets assets load quickly while keeping the application shell and sensitive data safe.

Internal Working

An ETag is an opaque validator chosen by the server. The browser sends it back with If-None-Match. If the content has not changed, the server can return 304 Not Modified with no body.

Last-Modified works similarly with If-Modified-Since, but it is timestamp-based and can be less precise than an ETag.

Architecture Discussion

Good frontend caching depends on deployment shape. Bundlers usually produce hashed static files, which are ideal for long-lived CDN and browser caching. HTML documents usually remain at stable URLs, so they need revalidation.

API caching depends on data volatility and user sensitivity. A product catalog can often be cached. A bank balance or permission response should be conservative.

Trade-Offs

Aggressive caching improves speed and reduces server cost. Conservative caching reduces stale-data risk. The right answer depends on the resource.

Caching bugs are painful because a fix may not reach users immediately if the broken response is already cached. That is why versioned URLs and invalidation plans matter.

Common Mistakes

A common mistake is setting a long max-age on HTML. After deployment, users may keep loading an old HTML shell that references old chunks or hides new UI.

Another mistake is using no-store everywhere. That avoids staleness but can waste bandwidth and slow repeat navigations.

Real Production Story

A release can break for only some users when stale HTML references JavaScript chunks that were removed from the CDN. The fix is usually to retain old assets long enough, avoid long-lived HTML caching, and use hashed filenames correctly.

Enterprise Example

In a SaaS dashboard, static assets can be cached for a year because filenames are content-hashed. The dashboard HTML can revalidate on each navigation. User-specific API responses should use private or no-store rules depending on sensitivity.

Performance Discussion

Caching improves repeat load, bandwidth usage, TTFB, and sometimes LCP. It does not replace first-load optimization. If the first visit downloads a huge bundle, caching only helps future visits.

Measure with DevTools Network panel. Look for memory cache, disk cache, 304, CDN hit headers, and response size.

Security Considerations

Sensitive data should not be stored in shared caches. Use private or no-store for user-specific data. Be careful with authenticated routes behind CDNs, especially when cookies or authorization headers are involved.

Scalability Discussion

Caching is one of the biggest scalability levers in frontend architecture. Correct CDN caching can reduce origin traffic massively. Incorrect caching can leak data or serve stale business-critical information.

Senior Engineer Perspective

A senior engineer should answer by resource type. Static assets, HTML, API data, images, and authenticated responses should not share one caching rule.

Lead Engineer Perspective

A lead should define caching defaults, deployment retention policy, CDN invalidation process, and debugging runbooks for stale response incidents.

Whiteboard Explanation

Draw browser, browser cache, CDN, and origin. Show a request being served from browser cache, then a conditional request that gets 304, then a cache miss that reaches origin.

Revision Notes

Use long immutable caching for content-hashed assets. Revalidate HTML. Be careful with user-specific and sensitive API data. no-cache allows storage with revalidation; no-store forbids storage.

Key Takeaways

HTTP caching is not one switch. It is a contract between resource freshness, deployment strategy, cache layer, and user correctness.

Related Topics

• Service workers
• CDN
• Critical rendering path
• Browser cache
• ETag
• Core Web Vitals

Practice Exercise

Design cache headers for a Next.js app with hashed assets, server-rendered product pages, account settings, avatars, and search suggestions. Explain the correctness risk for each resource.

Follow-Up Questions

1. What is the difference between no-cache and no-store?
2. What does max-age control?
3. What does immutable mean?
4. How does ETag revalidation work?
5. What is a 304 response?
6. Why should HTML usually avoid long immutable caching?
7. What is s-maxage?
8. How can CDN caching leak data?
9. How do hashed filenames affect caching?
10. How would you debug stale assets after deployment?

Things Interviewers Hate Hearing

"Use cache to make it fast" is not enough. You need to say which cache, which resource, how fresh it can be, and how it gets invalidated.

How I Would Answer This In A Real Interview

I would start by separating freshness from validation. A fresh cached response can be reused directly. A stale response can be revalidated with ETag or Last-Modified, and the server can return 304 Not Modified.

Then I would split by resource type. Hashed assets get long immutable caching, HTML gets revalidation, and sensitive data gets private or no-store behavior. Finally I would mention CDNs and service workers because cache bugs often come from misunderstanding which layer served the response.