Lesson 7 of 30

HTTP Caching & ETags

Q: How would you cache an API response that changes occasionally, without ever serving stale data or wastefully re-downloading unchanged data?

A strong answer covers: Cache-Control's max-age avoids a network round-trip entirely until it expires — good for content that truly never changes at a given URL; ETag + If-None-Match enables revalidation: the server responds 304 Not Modified with no body if the content hasn't changed, saving bandwidth while still making a round-trip; Distinguish no-cache (revalidate every time) from no-store (never cache) and public/private (shared cache eligibility).

Before a CDN ever gets involved, the browser and server already negotiate caching over plain HTTP headers — Cache-Control says how long to trust a copy, ETag says how to check if it's still valid without re-downloading it.

13 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

A request includes `If-None-Match: "abc123"` and the server's current content still has that same ETag. What does the server respond with?

304 Not Modified, with no body — the cached copy is confirmed still valid200 OK, with the full content re-sent to be safe404 Not Found, since the resource is now considered stale

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on HTTP Caching & ETags

What interviewers actually ask about this, and what a strong answer has to cover.

How would you cache an API response that changes occasionally, without ever serving stale data or wastefully re-downloading unchanged data?

A strong answer covers

Cache-Control's max-age avoids a network round-trip entirely until it expires — good for content that truly never changes at a given URL
ETag + If-None-Match enables revalidation: the server responds 304 Not Modified with no body if the content hasn't changed, saving bandwidth while still making a round-trip
Distinguish no-cache (revalidate every time) from no-store (never cache) and public/private (shared cache eligibility)

Likely follow-ups

Why is a long max-age safe for a content-hashed filename but risky for a plain, unhashed one?
What's the actual bandwidth/latency tradeoff between max-age and ETag-based revalidation?
When would you mark a response private versus public?

Practice these with the AI interviewer →

The plain-language idea

Cache-Control is the primary lever: Cache-Control: max-age=31536000 tells the browser "reuse this file for a year without even asking the server again." That's ideal for a content-hashed JS bundle (from the AWS lesson) — since a content change produces a new URL, the old URL really can be cached forever.

For content that does change but you still want to avoid re-downloading unnecessarily, ETag is the mechanism:

# First request
Response: 200 OK, ETag: "abc123"

# Later request
Request: If-None-Match: "abc123"
Response: 304 Not Modified   (no body sent at all)

The browser sends back the ETag it was given; if the server's current version has the same tag, it responds 304 Not Modified — confirming the cached copy is still good, without re-sending the file's body at all. If the content changed, the server sends a fresh 200 with the new content and a new ETag.

HTTP caching: reuse first, re-validate cheaply, redownload lastStep 1 of 3

Cache-Control: max-age=3600 — the browser can reuse this response for an hour without asking the server at all.

What people usually miss

Watch out

Cache-Control: no-cache doesn't mean "don't cache" — confusingly, it means "cache it, but revalidate with the server every time before using it" (essentially forcing the ETag/304 flow). no-store is the directive that actually means "never cache this at all."
private vs public matters for shared caches (a CDN, a corporate proxy) — private means only the end user's own browser may cache it (correct for anything containing personal data); public allows intermediate caches to store it too.
This is exactly the mechanism content-hashed filenames from the AWS lesson are designed around — a long max-age is only safe because the filename itself changes whenever the content does, so there's no "stale cache" risk to guard against with revalidation.

Why this matters in interviews

"How would you cache an API response that changes occasionally, without serving stale data or re-downloading unchanged data?" is a real, common question, and ETag-based revalidation is the concrete HTTP-level answer, distinct from (and complementary to) CDN edge caching.