stale-while-revalidate

Resilience Patterns

Meaning

Stale‑while‑revalidate (SWR) is a caching strategy where a cached response is served immediately even if it is stale, while a background request fetches fresh data to update the cache. It reduces latency for the user by avoiding waiting for network fetches, and it keeps data eventually consistent. The pattern is used when the application can tolerate slightly out‑of‑date information but wants to keep the cache up to date without blocking the request.

Primary Function

Caching strategy

Communicative Purpose

Ensures low‑latency responses while keeping cached data eventually fresh.

Pattern

read from cache → return cached value (even if stale) → trigger async refresh → update cache

Função primária

Caching strategy

Propósito comunicativo

Ensures low‑latency responses while keeping cached data eventually fresh.

Situações de gatilho

Web API client: frequent read‑only endpoint with occasional updates Mobile app: displaying user profile where slight staleness is acceptable Edge server: serving static assets that change infrequently

Contextos

Web applications, CDN edge servers, client‑side data‑fetching libraries (e.g., React SWR, Vue useSWR), API gateways

Padrão

read from cache → return cached value (even if stale) → trigger async refresh → update cache

Colocados típicos

cache miss
background fetch
revalidation
TTL
freshness
optimistic UI

Substituições comuns

Using a simple time‑based expiration (no background refresh) – reduces complexity but increases latency Using a write‑through cache – ensures freshness but adds write overhead

Erros comuns

Assuming stale data is always acceptable, leading to UI showing outdated information → user confusion Not handling errors in the background refresh, causing the cache to remain stale indefinitely → data becomes increasingly out‑of‑date Updating the cache without proper synchronization in concurrent environments, causing race conditions → corrupted cache entries Setting the revalidation interval too short, causing excessive load on origin servers → performance degradation

Similar / contraste

Cache‑aside (pull) – only fetches on miss, no background refresh Write‑through – updates cache on every write, ensures freshness but higher write latency Stale‑if‑error – serves stale data only on fetch failure, not proactive

Interferências

Coming from Python: using `functools.lru_cache` without a background refresh → does not implement stale‑while‑revalidate semantics Coming from JavaScript: assuming `fetch` returns cached data automatically – browsers need Service Workers to implement SWR

Família do chunk

cache‑control directives
read‑through cache
write‑through cache
lazy loading
optimistic UI

Nuance

Do not use SWR for data that must be strictly consistent, such as financial transactions Background revalidation adds extra network requests; on high‑traffic endpoints this can increase load If the cache store does not support atomic updates, race conditions may cause stale data to be overwritten incorrectly

Efeito pragmático

Provides fast perceived performance for end‑users while keeping data reasonably fresh, reducing server load compared to always‑fresh fetches.

Dica de memória

Think of a coffee shop that serves yesterday’s brew to a waiting customer while the barista prepares a fresh pot in the background.

Nota

SWR is popularized by the HTTP `Cache-Control` directive `stale-while-revalidate` and by libraries such as Vercel's SWR for React.

Upgrade path

Implement stale‑while‑revalidate with stale‑if‑error and cache‑stale‑while‑revalidate headers for full HTTP cache control.

Frequência: HighFormulaicidade: FixedTipo de construção: conceptPrioridade de aquisição: Active recallPrioridade de output: BothTag de espaçamento: Medium-term

Examples

import requests import requests_cache # Configure a SQLite cache with stale‑while‑revalidate of 60 seconds requests_cache.install_cache('demo_cache', expire_after=300, stale_if_error=True) def fetch_user_profile(user_id): url = f'https://api.example.com/users/{user_id}' response = requests.get(url) # The first call may be a cache miss; subsequent calls within 60 s return stale data # while a background thread refreshes the entry. return response.json() print(fetch_user_profile(42))

import useSWR from 'swr'; import fetch from 'unfetch'; const fetcher = url => fetch(url).then(r => r.json()); function UserProfile({ userId }) { const { data, error } = useSWR(`/api/users/${userId}`, fetcher, { revalidateOnFocus: false, dedupingInterval: 60000 }); if (error) return <div>Failed to load</div>; if (!data) return <div>Loading…</div>; return <div>Name: {data.name}</div>; } export default UserProfile;

package main import ( "net/http" "sync" "time" ) type cacheEntry struct { data []byte timestamp time.Time } var ( cache = make(map[string]cacheEntry) mu sync.RWMutex ttl = 5 * time.Minute staleRe = 1 * time.Minute // serve stale for this duration while revalidating ) func staleWhileRevalidate(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { key := r.URL.String() mu.RLock() entry, ok := cache[key] mu.RUnlock() if ok && time.Since(entry.timestamp) < ttl+staleRe { // Serve cached (possibly stale) response w.Write(entry.data) // Trigger async refresh if stale if time.Since(entry.timestamp) > ttl { go func() { resp, err := http.Get("https://origin.example.com" + key) if err != nil { return } body, _ := io.ReadAll(resp.Body) resp.Body.Close() mu.Lock() cache[key] = cacheEntry{data: body, timestamp: time.Now()} mu.Unlock() }() } return } // No cache entry – fall back to upstream next.ServeHTTP(w, r) }) } func main() { mux := http.NewServeMux() mux.HandleFunc("/data", func(w http.ResponseWriter, r *http.Request) { w.Write([]byte("fresh data at " + time.Now().String())) }) http.ListenAndServe(":8080", staleWhileRevalidate(mux)) }