HTTP Caching

HTTP caching controls how responses are stored, reused, and expired to reduce latency and bandwidth usage. It includes Cache-Control directives, ETags, Last-Modified, Vary headers, and covers proxy and CDN behavior, cache hierarchies, TTL strategies, and cache key design. Architectural decisions balance consistency, freshness, invalidation complexity, scalab…

Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.

Content type

Concept

Theoretical construct: explains a term, principle, or mental model.

Classification level

Structure

What organizes, connects, or makes decisions possible.

Available perspectives

Open this building block directly in an already curated view.

360°

In brief

HTTP caching in brief

HTTP caching stores responses temporarily so later requests can be served faster with less network and server load.

Where does it come from?

It grew from the need to make repeated web retrieval efficient and was standardized through HTTP specifications. RFC 7234 defines HTTP/1.1 cache semantics; the development has no single originator.

The mental model

A cache uses Cache-Control, freshness, and validators to decide whether a stored response can be reused. A fresh response avoids a fetch; a stale one may be revalidated with ETag or Last-Modified and return 304. Wrong cache keys or missing invalidation can serve stale or private content.

Key building blocks

Freshness

Expiry rules determine how long a response may be used without rechecking.

Validator

ETag or Last-Modified enable conditional requests that save transfer.

Invalidation

Changes must prevent caches from serving content that is no longer valid.

When is it useful?

Caching improves latency, scale, and cost. It requires explicit rules for personal, dynamic, and security-sensitive content to preserve freshness and confidentiality.

IETF RFC 7234 - HTTP/1.1 Caching