Script Valley
System Design: APIs, Caching & Scalability
Caching FundamentalsLesson 2.4

HTTP caching with Cache-Control headers

Cache-Control header, max-age directive, no-cache vs no-store, ETag and conditional requests, stale-while-revalidate, CDN caching, browser caching

HTTP caching with Cache-Control headers

HTTP Cache-Control flow

Caching at the Protocol Layer

HTTP has built-in caching semantics. Set the right headers and browsers, CDNs, and reverse proxies cache your responses automatically — zero application code needed.

Cache-Control Directives

# Cache for 1 hour, CDN and browser both cache
Cache-Control: public, max-age=3600

# Never cache sensitive data
Cache-Control: no-store

# Revalidate before each use (forces ETag check)
Cache-Control: no-cache

# Serve stale while revalidating in background
Cache-Control: public, max-age=60, stale-while-revalidate=300

no-cache does NOT mean do not cache — it means always revalidate with origin before serving. no-store means truly never cache. This distinction trips up many developers.

ETags and Conditional Requests

An ETag is a hash of the response body. The client sends it back via If-None-Match. If unchanged, the server returns 304 Not Modified with no body — saving bandwidth:

# Server response
ETag: "d8e8fca2dc0f896fd7cb4cb0031ba249"

# Client next request
If-None-Match: "d8e8fca2dc0f896fd7cb4cb0031ba249"

# Server if unchanged
HTTP/1.1 304 Not Modified

Use stale-while-revalidate for near-real-time content where occasional stale responses are acceptable — it dramatically improves perceived performance without sacrificing freshness over time.

Up next

Redis as a cache: patterns and best practices

Sign in to track progress