Caching — layers, strategies, invalidation

Caching = keep a copy of expensive-to-compute data somewhere faster to read. Classic target: DB queries and API responses. Typical win: 100ms → 1ms, and the DB doesn't melt under load.

**Multiple cache layers** in a real system: **browser cache** (static assets), **CDN** (Cloudflare, CloudFront — edge cache close to users), **app-level cache** (in-memory LRU in each instance), **distributed cache** (Redis / Memcached — shared across instances), **DB cache** (query plan cache, buffer pool). Each layer is faster than the next one behind it.

**Read strategies**: **cache-aside** (app checks cache → miss → fetch DB → populate cache → return) — most common. **Read-through** (cache lib fetches on miss transparently). **Write-through** (write to cache and DB atomically — consistent but slower). **Write-behind** (write to cache, async flush to DB — fast, lossy on cache failure).

**Eviction policies** (cache is bounded): **LRU** (Least Recently Used — classic, good general fit), **LFU** (Least Frequently Used — better for Zipfian distributions), **TTL** (expire after N seconds — simplest), **FIFO** (oldest first, rarely used). Most tools offer LRU + TTL.

Cache invalidation is hard. Phil Karlton's famous joke: 'There are only two hard things in Computer Science: cache invalidation and naming things.' When the underlying data changes, how do you know to drop the cache? Strategies: TTL (stale for N seconds, cheap), explicit invalidation on write (complex, precise), event-driven (pub/sub on data changes).

**Cache stampede**: expired key + 1000 concurrent requests → all 1000 hit the DB at once. Mitigation: locking (only first request fetches, others wait), probabilistic early expiration (renew before expiry), jitter on TTL.