Eye Training · Caching and Memoization

A cache is a copy. Every caching bug is a copy that is wrong, shared, stale, unbounded, or rebuilt by everyone at once.

Part 2 · Surface 17. Bug counts are hidden and some snippets are clean. See Start Here for how to use these drills.

J · The basics

M · Three years in, these should jump out

S · Where seniors stand out

What your eye checks

Whenever you see a cache, a Map used as one, or a memoize, ask:

1. Is every input in the key? Page, filters, locale, user, tenant, version. A missing one means wrong data; a missing user means leaked data.
2. When does it expire, and what clears it on change? No TTL plus no invalidation means stale forever.
3. Write first, then invalidate. Deleting the key before the write lets a reader cache the old value.
4. Is the hit check correct for every value? if (cached) treats 0, '' and false as misses.
5. Can a caller mutate the cached value? Shared objects need copying or freezing.
6. Are failures cached? A rejected promise or an error result shouldn't stick.
7. Is it bounded? A Map that only grows is a memory leak with a delay.
8. What happens when a hot key expires? Stampede: lock, single-flight, serve stale, jitter.
9. Is it per instance? In-process caches differ across instances and survive role changes; who tells them to forget?
10. HTTP: public versus private; personal responses must never go to a shared cache.

Tells

Go deeper

• Controlling Concurrency: Part 4, single-flight and the rejected-promise trap
• SD 1 · Caching: cache-aside, invalidation and stampedes at the system level
• Previous surface: fetch and the network · Next: Shared state and races