HTTP Cache Revalidation

Cache revalidation checks whether a cached HTTP response can still be reused by consulting the origin or an intermediary, typically without transferring the full representation when it has not changed. It reduces bandwidth and latency while keeping cached data consistent with server state.

Revalidation is used when a cached response is eligible for conditional reuse rather than being blindly served forever. A client or cache sends a conditional request containing information about its stored representation, commonly an `ETag` or `Last-Modified` value.

With an `ETag`, the validator is sent in `If-None-Match`; with a modification timestamp, it can be sent in `If-Modified-Since`. If the origin determines that the cached representation is still current, it returns `304 Not Modified`, which carries no response body and allows the cached representation to be reused.

If the representation has changed, the origin normally returns a regular successful response such as `200 OK` containing the new representation and potentially new cache metadata. The cache then replaces or updates its stored response according to the applicable HTTP caching rules.

Revalidation is different from expiration itself. A freshness directive such as `max-age` determines how long a response can normally be used without contacting the origin; once freshness no longer permits unconditional reuse, a cache may need to revalidate before serving it. Directives such as `must-revalidate` can further restrict serving a stale response without successful validation.

Key points

• `ETag` commonly pairs with `If-None-Match` for conditional validation.
• `Last-Modified` commonly pairs with `If-Modified-Since`.
• `304 Not Modified` tells the cache that its stored representation can be reused.
• A changed representation normally results in a response containing the new representation, often `200 OK`.
• Freshness and validation are related but distinct: freshness controls whether validation is needed, while validators determine whether the stored representation remains usable.

Interview questions

What is HTTP cache revalidation?

Cache revalidation is the process of checking with the origin whether a cached representation is still current before reusing it. The cache sends a conditional request using a validator such as an `ETag` or `Last-Modified` value. If the representation has not changed, the server can return `304 Not Modified`, allowing the cache to reuse its stored body. If it changed, the server sends the newer representation instead.

How do `ETag` and `If-None-Match` work together?

An origin can associate an `ETag` with a representation. A cache stores that tag and later sends it in `If-None-Match` when making a conditional request. If the validator matches according to the HTTP comparison rules, the server can return `304 Not Modified`, so the stored representation can be reused. If it does not match, the server can return the current representation.

What is the difference between freshness and revalidation?

Freshness determines whether a cache can use a stored response without contacting the origin. For example, `Cache-Control: max-age` can establish a freshness lifetime. Revalidation is the subsequent conditional check used when the cache cannot simply reuse the response without validation. Therefore, a response can be cached but require a network validation before it is served.

Why is cache revalidation useful for backend systems?

Revalidation can preserve the latency and bandwidth advantages of caching while limiting how long a representation can remain unchecked. When the representation has not changed, a `304` response avoids retransmitting the response body. This is especially useful for large or frequently requested resources. The tradeoff is that revalidation still requires a network request and therefore does not provide the same savings as serving a fresh cache hit.

What should you consider when designing cache validation for a Java backend API?

First, identify which representations are safe and useful to cache and choose validators that accurately represent the selected representation. An API can emit an `ETag` and appropriate `Cache-Control` directives, then honor conditional requests such as `If-None-Match`. The design should also account for representation variants, because content negotiation or other request-dependent differences can affect whether a cached representation is reusable. Finally, caching rules must align with application correctness, especially for user-specific or rapidly changing data.