Where caches live
Patterns
| Pattern | How | When |
|---|---|---|
| Cache-aside (lazy) | App reads the cache; on miss, reads the DB and fills the cache | Default for read-heavy data |
| Read-through | Cache library loads from the DB on miss | Same idea, less app code |
| Write-through | Write the cache and DB together | Data read right after it's written |
| Write-behind | Write the cache; flush to the DB asynchronously | Very write-heavy, loss-tolerant (counters) |
| Refresh-ahead | Refresh hot keys before they expire | Predictable hot sets |
The hard part: invalidation
- TTL as a safety net, always, even with explicit invalidation.
- Event-driven invalidation:
EntryPublished→ purge the CDN path and delete the Redis key. - Versioned keys:
entry:42:v17. New versions never collide, and old ones expire naturally. - Delete, don't update, the cache on write. This avoids races that write stale data back.
Failure modes
- Stampede / thundering herd: a hot key expires and 10k requests hit the DB. Fix with a request-coalescing lock, early probabilistic refresh, or stale-while-revalidate.
- Cache penetration: repeated requests for keys that don't exist. Cache negative results briefly, or use a Bloom filter.
- Hot key: replicate it or use a local in-process cache.
- Plan for the cache being down: the DB must survive at least degraded traffic.
Headless CMS delivery is a caching problem first: published content sits behind a CDN, and every publish, unpublish or release deploy has to trigger precise purges. Getting purge scope right (by entry, content type, locale and environment) matters as much as the cache itself.
Cheatsheet
The whole topic on one page. Click to open full screen.
Sources & further learning
Videos, courses, docs and books I recommend for this topic.
Related topics
CQRS (Command Query Responsibility Segregation)
Use one model to change data (commands) and a different, optimised model to read it (queries) — often kept in sync by events.
Design: URL Shortener
The classic warm-up — ID generation, read-heavy caching, redirects at scale and analytics without slowing the hot path.
MongoDB at Enterprise Scale
Data modelling by access pattern, indexing (ESR rule), transactions, change streams and the operational gotchas of large multi-tenant collections.