Cache-aside vs write-through and cache stampede prevention
Parent: Read Offload via Caching and Precomputed Views ($merge/$out, Computed Pattern) · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Cache-aside vs write-through and cache stampede prevention. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- Write-through updates the cache when the backing store is written. It trades additional write work and potentially unused cached entries for fewer subsequent read misses. (medium confidence) [source]
- The groupcache singleflight implementation stores in-flight calls in a Group-local map and deletes the entry after completion. It suppresses overlapping work within that Group; it neither retains a cached value nor coordinates separate processes. A shared lock service is a separate coordination mechanism. (medium confidence) [source]
- A cache can add overhead when most reads miss. Assess hit rate and freshness requirements before assuming that caching an expensive query result or precomputed value will improve read offload. (medium confidence) [source]
Problems, failure modes and limitations
- Do not interpret write-through as automatic atomicity across two stores. Readers seeing the new value depends on successful coordinated writes; a partial failure can leave divergent values that require recovery. (medium confidence) [source]
- Cache-aside alone does not detect every database update. Explicit invalidation and TTLs limit stale copies, but concurrent fills, reordered writes, and writers bypassing the cache can still create stale windows. (medium confidence) [source]
- A cache stampede occurs when concurrent requests miss the same popular key and independently regenerate it. More backend work can slow regeneration and widen the miss window, creating a feedback loop. (medium confidence) [source]
- TTL jitter staggers expiration across different keys. It does not itself serialize concurrent misses for one expired hot key; combine it with per-key fill coordination when that workload is possible. This limit follows from the distinct mechanisms described by the sources. (medium confidence) [source]
- Lock-based stampede protection needs failure handling: waiters can remain without a fresh value if the refresher fails, and lock expiry must allow recovery. A remote lock service also introduces latency and an availability dependency. (medium confidence) [source]
- Cache-aside and write-through are complementary: demand loading can refill entries missing after eviction or node failure even when writes proactively populate the cache. (medium confidence) [source]
- A cache stampede occurs when concurrent misses regenerate the same expired popular entry. More requests and slower regeneration increase duplicate work; the overload can further slow regeneration and amplify the failure. (high confidence) [source]
- During a coordinated refresh, other callers can wait or receive a retained stale value if the application permits staleness. A cold miss has no prior value to serve, so stale-serving behavior cannot replace a cold-miss policy. (medium confidence) [source]
- Locks add coordination latency and failure modes. A failed refresh owner can leave callers waiting or serving stale data until lock expiry; lock lifetime must account for regeneration duration and recovery. (medium confidence) [source]
Comparisons and alternatives
- Probabilistic early refresh uses randomized decisions before expiry to reduce coordinated regeneration without an external lock service. It is a load-control trade-off rather than an exact one-refresher guarantee. (medium confidence) [source]
Facts and statements
- Cache-aside checks the cache first; a miss makes the application read the database, populate the cache, and return the result. This offloads repeated reads but leaves a slower miss path. (medium confidence) [source]
- Write-through updates the cache and backing database on each write. Waiting for both increases write latency and can populate the cache with data that is never read. (medium confidence) [source]
- Per-key request coalescing lets one caller regenerate while duplicate callers share its result. Shared cache entries alone do not provide this coordination. (medium confidence) [source]
- The inspected groupcache singleflight implementation stores in-flight calls in a Group-local map guarded by a mutex. It suppresses duplicates within that Group; this primitive alone does not coordinate independent application processes or retain completed results. (low confidence) [source]
- A per-key lock can elect a refresher while other requests wait or receive a retained stale value. Serving stale data requires an application policy that accepts those older results. (medium confidence) [source]
- Moving every refresh a fixed interval before expiry merely moves the herd earlier unless refresh requests are collapsed or otherwise limited. (low confidence) [source]
- A Hyperswitch issue dated 2026-09-29 reports that get_or_populate_redis executed the fallback 100 times for 100 concurrent requests to one missing key. This is a reporter-provided reproduction, not an independently verified production outage or a statement about the current fix status. (low confidence) (verified as of 2026-10-31) [source]
- With cache-aside, the application checks the cache, fetches a miss from the backing store, then populates the cache. Only requested entries consume cache space. (high confidence) [source]
- Cache-aside does not guarantee consistency. Update the backing store before invalidating its cached entry; deleting first permits a reader to reload the old value before the write finishes. External writers and concurrent fills still require consistency handling. (medium confidence) [source]
- Probabilistic early refresh reduces stampedes without a shared coordination service, but it does not guarantee exactly one refresh. A fixed early-refresh window with every request refreshing merely moves the herd earlier. (medium confidence) [source]
Children
- Cache fill races and version-aware invalidation (frontier)
- Per-key request coalescing across processes (frontier)
- Bounded stale serving during refresh (frontier)
- Probabilistic early expiration (frontier)
- TTL jitter and correlated expiration (frontier)
- Per-key request coalescing and singleflight scope (frontier)
- TTL jitter across keys (frontier)
- Stale-while-revalidate policies (frontier)
- Probabilistic early refresh and XFetch (frontier)
- Cache invalidation ordering and write recovery (frontier)
Frontier under this node: Bounded stale serving during refresh, Cache fill races and version-aware invalidation, Cache invalidation ordering and write recovery, Per-key request coalescing across processes, Per-key request coalescing and singleflight scope, Probabilistic early expiration, Probabilistic early refresh and XFetch, Stale-while-revalidate policies, TTL jitter across keys, TTL jitter and correlated expiration