Caching questions come up in the same order every time. Here are the answers, with the specific headers and values rather than the general principle.
Three patterns cover almost everything. For fingerprinted static assets — files whose names contain a content hash — use Cache-Control: public, max-age=31536000, immutable: one year, and the browser will not even revalidate. For HTML that must always be fresh but can survive a moment of staleness, Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=86400: browsers revalidate every time, the CDN serves for five minutes, and for a day after that it serves stale content instantly while refreshing in the background. For anything user-specific, Cache-Control: private, no-store. Note that no-cache does not mean do not cache — it means store it but revalidate before use. no-store is the one that means do not keep it.
Work backwards from how stale the data may be, not from a habit. Content that changes on publish and is purged on deploy can have a long CDN TTL because you control invalidation. Data you cannot invalidate must have a TTL equal to the staleness you can tolerate. A pricing endpoint that must be accurate within a minute gets 60 seconds, and no amount of wishing makes it longer. When in doubt, a short TTL with stale-while-revalidate gives you most of the hit rate of a long one without the staleness risk.
Preferably by not invalidating it. Content-hashed filenames mean a new version is a new URL, so nothing needs purging — this is why the year-long immutable asset TTL is safe. Where you must purge, tag-based purging (available on most CDNs via a surrogate key header) lets one product update clear the twelve pages that reference it, which is far more precise than purging a path prefix and far cheaper than purging everything. Purging the whole cache is a valid emergency tool and a bad routine, because your origin then absorbs the full reload.
A popular key expires and every concurrent request misses simultaneously, all hitting the origin at once — which is exactly how a cache turns into an outage amplifier. Three defences, best used together: a lock so only the first request recomputes while the others wait or serve stale; stale-while-revalidate, which makes this the default behaviour at the CDN layer; and jittered TTLs so a thousand keys written together do not expire together. Never set the same fixed TTL on a large batch of keys.
Cache-aside — the application checks the cache, falls back to the database, and populates on miss. Simple, resilient, and the default answer. Write-through — writes go to cache and database together, keeping them consistent at the cost of write latency, useful when reads must never be stale. Write-behind — writes hit the cache and flush to the database asynchronously; fast and capable of losing data if the cache dies. Use cache-aside unless you can articulate why not.
Run curl -sI https://example.com/page and read the cache status header. The usual causes, in order of frequency: a Set-Cookie header on the response, which makes most CDNs refuse to cache; Cache-Control: private or no-store from the framework's default; a Vary header on something high-cardinality like User-Agent, which fragments the cache into near-unique entries; or query parameters creating a separate cache key per tracking URL. Strip marketing parameters at the edge and set Vary: Accept-Encoding only.
As close to the user as it can be while still being correct. Browser cache is free and fastest but you cannot purge it, which is why HTML gets a short max-age. CDN cache is shared across users and purgeable, so it is where most of the win is. Application cache (Redis) handles computed values and query results. Database query cache and connection pooling handle the rest. Adding a Redis layer before you have set correct HTTP headers is solving the fourth problem first.
Free tools, guides, and resources across the SPUNK13 network.
Visit spunk.bet400+ Free Tools