Topic 10.7
Cache Invalidation
In one line
The hardest problem in computer science, at least for interviews: keeping the cache honest after writes.
Think of it like this
Updating a printed poster on a notice board. If you change the real schedule but forget to take down the old poster, people keep reading stale information. Cache invalidation is remembering to update or remove that poster the moment the truth changes.
Key ideas
- 01
Invalidate-on-write (delete key) is safer than write-through: it avoids a whole race class between db-write and cache-write order.
- 02
TTL is the lazy invalidation floor: even if you forget, data self-heals — never a cache without a TTL.
- 03
Patterns: delete-on-write, versioned keys (?v=), cache-aside + DB trigger/event → invalidate, feature-level namespace keys.
- 04
The double-write race: write DB then cache (crash between = stale); write cache then DB (crash between = lost read-freshness). Delete-on-write sidesteps it.
- 05
Cache stampede IS an invalidation symptom: all copies expire together → single-flight + jitter (Phase 10.2 / blog).
- 06
Interview line: 'I invalidate on write and keep a TTL as the safety net — no legendary cache is worth debugging without both.'
Java / Spring map
- →
Spring @CacheEvict with @CachePut alternatives; Kafka event → evict in a read model.
Code & diagrams
Explain without notes
Why is delete-on-write safer than write-through for the DB↔cache consistency race? Walk the crash point.
Practice
Design invalidation for a profile API updated by an admin console and read by 10 services.
Trade-offs
- ↔
No cache is perfectly fresh; the design question is bounding staleness, not eliminating it.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I always include TTL + eviction and can walk the crash races.