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
Deciding when to throw a cached value away, and naming the keys. Phil Karlton, then at Netscape, is widely credited with the line about cache invalidation and naming things being the two hard problems in computer science.
Where to cache
Browser, CDN, app memory, a shared cache such as Redis, or the database itself.
Strategies
Cache-aside (also called read-through), write-through, and write-behind.
TTL vs explicit invalidation
Expire on a timer, or clear the key yourself when the data changes. Stale-while-revalidate serves the old value and refreshes in the background.
The thundering herd
A hot key expires and every request hammers the database at the same moment.
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 versus recompute.
Drill the React-perf version →