“What is the cache key?”
Name every representation-changing input and explain how you avoid unsafe collisions and uncontrolled cardinality.
Quick reference · Print-friendly
Cache correctness field guide
For every value: audience, key, staleness, invalidation, failure.
Policy worksheet
| Question | Examples | Failure if omitted |
|---|---|---|
| What is cached? | HTML, RSC payload, JSON, query result, asset | You purge one representation while another stays stale. |
| Who may share it? | Everyone, region, tenant, one user, one browser | Personalization or authorization leaks across audiences. |
| What forms the key? | Path, query, locale, region, tenant, content version | Distinct variants collide or cardinality destroys hit rate. |
| How stale may it be? | Immutable, hours, seconds, never for decisions | The infrastructure silently chooses product semantics. |
| How does it leave? | TTL, validator, tag, purge, versioned URL | Updates fail to propagate or create origin spikes. |
HTTP directive decoder
| Directive | Meaning | Common mistake |
|---|---|---|
max-age=N | Freshness lifetime for caches, including private caches | Assuming it guarantees origin-current data |
s-maxage=N | Freshness lifetime for shared caches; overrides max-age there | Forgetting the browser and CDN now have different policies |
private | May be stored only by a private cache | Treating it as equivalent to no storage |
no-cache | May store; must validate before reuse | Reading the name as “do not cache” |
no-store | Do not store this response | Adding it everywhere and losing useful browser behavior |
stale-while-revalidate=N | May serve stale for N seconds while validating asynchronously | Ignoring how many stale versions users may observe |
stale-if-error=N | May serve stale for N seconds when origin fails | Using it for data where stale is less safe than unavailable |
immutable | Representation will not change during freshness lifetime | Using it on URLs whose contents can change |
Interview decision sequence
- Split the page into data classes instead of assigning one route-wide freshness label.
- State the accepted staleness and consistency requirement for each class.
- Select the sharing audience and enumerate every key dimension.
- Choose TTL, event invalidation, conditional validation, or versioned URLs.
- Keep permissions, money, quotas, and inventory authoritative at mutation time.
- Trace invalidation through browser, CDN, application, and data caches.
- Plan stampede control, stale-on-error policy, and a bounded expiry backstop.
- Observe hit ratio, Age/Cache-Status, purge lag, stale responses, and origin load.
Follow-up prompts to expect
“What if invalidation is lost?”
Use reliable events plus a bounded TTL backstop, observability, and manual purge capability.
“What happens during a spike?”
Discuss request coalescing, early refresh, jitter, bounded stale serving, and origin protection.
“How do writes appear immediately?”
Use write-through/update or targeted expiry for read-your-own-writes rather than background SWR.