Cache consistency is the idea that the cache and the source of truth (e.g. DB) agree. When the DB changes, the cache can still hold old data — that’s stale cache. Staleness can cause wrong reads until the cache is updated or expired.
Why staleness happens
sequenceDiagram
participant C as Client
participant Cache as Cache
participant DB as Database
C->>Cache: Read key X
Cache-->>C: value v1
Note over DB: Someone updates DB: X = v2
C->>Cache: Read key X (still v1)
Cache-->>C: v1 (stale)
Ways to reduce staleness
TTL — Accept staleness for TTL; then re-fetch. Simple; can be stale up to TTL.
Invalidate on write — On DB update, delete (or update) the cache key. Cache and DB can be consistent if invalidation is reliable.
Write-through — Write to cache and DB together. Cache stays in sync but every write hits both.
Write-behind — Write to cache first, async to DB. Low latency but risk of loss and more staleness if DB is source of truth.
flowchart TB
W[Write to DB] --> I[Invalidate cache key]
I --> Next[Next read = cache miss]
Next --> F[Fetch from DB]
F --> Store[Store in cache]
Strong consistency between cache and DB is hard in distributed systems. Often use short TTL + invalidation on write, and accept brief staleness for non-critical data.