Caching
SWR: multiple-choice review
Crux Multiple-choice synthesis across the SWR unit — the two windows, single-flight, stale-if-error, client revalidation, and the auth hazard.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each mirrors a header you write or an incident you triage — not a directive to memorise, but a freshness-versus-latency trade to weigh under real traffic.
Goal
Confirm you can connect the freshness window, the SWR window, stale-if-error, single-flight, and the client revalidation model — and that you know the one place SWR must never go.
Quiz
Completed
A request arrives 90 seconds after caching, with Cache-Control: max-age=60, stale-while-revalidate=300. What does the user get and why?
Heads-up That is plain max-age behaviour. Inside the SWR window the entire point is that the user is not blocked — stale now, refresh out of band.
Heads-up It only becomes a hard miss after max-age + SWR window (60+300=360s). Between 60s and 360s it is stale-but-serveable.
Heads-up The 'while' means the refresh runs while the stale response is already on its way. Synchronous revalidation is exactly what SWR removes.
Quiz
Completed
Why does max-age alone produce a per-TTL p99 sawtooth, and how does stale-while-revalidate flatten it?
Heads-up max-age does NOT revalidate every request — it serves from cache until expiry. The spike comes only at the TTL boundary, where the refill blocks a live user. That is what SWR moves out of the request path.
Heads-up The spike is not origin variance — it is the synchronous refill landing in a user's request. SWR does not average anything; it just stops a human from waiting on the refresh.
Heads-up SWR does not change max-age or per-miss cost; it changes WHO pays the miss — a background fetch instead of a live user. The origin round-trip is the same size, just nobody waits on it.
Quiz
Completed
A popular key expires under 10k req/s and the edge fires one background revalidation per stale-hit. What breaks and what is the fix?
Heads-up The user is not waiting, but the origin still receives every refresh. Thousands of concurrent background fetches can melt the origin just like a foreground stampede.
Heads-up Removing SWR brings back the synchronous-revalidation spike. The herd is about coalescing concurrent refreshes, not about the staleness window.
Heads-up Users get stale-but-fast responses, not errors. Raising max-age does not stop concurrent background fetches stampeding the origin.
Quiz
Completed
What does stale-if-error add on top of stale-while-revalidate, and why is pairing them the senior default?
Heads-up They are independent and mirror images: stale-while-revalidate is for a healthy origin you do not want users to wait on; stale-if-error is for a sick origin where stale beats a 503.
Heads-up Neither directive blocks the user. stale-if-error simply changes what happens when the background refresh FAILS — keep serving stale instead of propagating the error.
Heads-up It adds a separate, usually longer, failure-only window. It does not touch the SWR window or normal staleness — it is a floor under outages.
Quiz
Completed
Two components call useSWR('/api/user') in the same render tick. What does the SWR client library do, and what governs it?
Heads-up Duplicate calls for the same key are coalesced onto one in-flight request inside dedupingInterval — that is the whole point of the client cache layer.
Heads-up There is no blocking and no second fetch. Both components subscribe to the single in-flight promise and get the same cached result.
Heads-up The question is about deduplication of concurrent calls, not first-load UI. SWR coalesces them into one request regardless of whether the key was seen before.
Quiz
Completed
For which response is stale-while-revalidate the wrong tool, and why?
Heads-up That is the textbook SWR fit — bounded staleness is harmless and the p99 sawtooth is the real cost. SWR is exactly right here.
Heads-up Slightly-stale analytics is fine; SWR serves it instantly and self-corrects in the background. Nothing about it is a correctness or security hazard.
Heads-up Static-ish content tolerates staleness perfectly; SWR is an ideal fit. The wrong target is data where stale equals a security or correctness bug, like auth.
Recap
The through-line is one contract: return what you have now, fetch what is correct next, never block the human on the refresh. max-age sets freshness, the SWR window kills the synchronous-revalidation sawtooth, stale-if-error turns an outage into degraded-but-up, single-flight plus jitter stops the background-refresh herd, and the client libraries reproduce the same model with dedupingInterval and focus/reconnect revalidation. The one hard boundary: never apply SWR to auth, permissions, or anything where stale data is a security bug.