Stale-while-revalidate
Slap yourself if
You think stale-while-revalidate is just 'fast caching' or assume users never see stale data.
Why this exists
Because stale-while-revalidate is widely adopted for perceived performance while teams quietly ship consistency bugs, race conditions, and trust-breaking UI states.
Mental model
Stale-while-revalidate is a latency optimization that explicitly allows serving outdated data while correctness catches up asynchronously. You are choosing speed over immediate consistency.
- A cached response is served immediately, even if stale.
- A background revalidation request is triggered.
- The cache may be updated after the response is already used.
- Subsequent requests may see a different version of reality.
- Assuming stale data is invisible to users.
- Triggering UI updates based on background revalidation.
- Combining SWR with stateful or user-specific data.
- Failing to reconcile stale UI with fresh responses.
Stale-while-revalidate serves cached responses immediately and updates them asynchronously, trading consistency for lower latency.
- Claims users never see stale data.
- Treats it as safe for mutations.
- Ignores UI reconciliation.
- Frames it as a correctness strategy.
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.