Caching
The cheapest speed win — and the source of the weirdest bugs.
Caching is how you make a slow thing fast and a costly thing cheap. It's also where 'why is the user seeing stale data?' is born. What to cache and when to throw it away is judgment AI can't do for you — it depends on how much staleness your product can tolerate.
Ready to test yourself on this kind of call?
Drill the React-perf version →What you own
- ▪What's safe to cache and for how long (the staleness call)
- ▪The invalidation strategy
- ▪Which data must never be stale
- ▪The cost/benefit of each cache layer
▸Hand to AI (4)
- Wrapping a function in a cache layer
- Writing the cache-key logic
- Redis / CDN config
- A stale-while-revalidate wrapper
What to learn (the durable stuff)
The two hard things
cache invalidation (when to throw it away) and naming the keys.
Where to cache
browser, CDN, app memory, a shared cache (Redis), or the database.
Strategies
cache-aside (read-through), write-through, write-behind.
TTL vs explicit invalidation, and stale-while-revalidate (serve stale, refresh in the background).
The thundering herd
a hot key expires and every request hammers the DB at once.
What NOT to cache
anything where stale equals wrong (balances, permissions, prices).
Current tools (these change fast)
Practice this scenario
Your React table renders 5,000 rows and one keystroke in a filter input re-renders the whole table. Estimate the wall-clock delay on a mid-tier laptop, and say what you'd fix — and what you'd cache vs recompute.
Drill the React-perf version →