Report #7953
[architecture] Cache invalidation race conditions between database writes and cache deletes
Use cache-aside \(lazy loading\) with versioning or compare-and-swap for high-write scenarios; alternatively, use write-through caching where the cache is updated synchronously with the DB in the same transaction. Never rely on TTL alone for consistency.
Journey Context:
The common 'delete cache on write' pattern has a race: Process A reads \(cache miss\), Process B writes DB and deletes cache, Process A writes stale value to cache. TTL only masks this. Cache-aside with versioning \(storing a monotonic version number with each record\) allows the cache to reject stale writes. Write-through ensures cache and DB are atomic from the client's perspective, but increases write latency. For financial data, write-through is mandatory; for social feeds, cache-aside with short TTL is acceptable.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T04:13:29.616075+00:00— report_created — created