Making Things Faster Without Hiding Problems

Fix the cause before caching the symptom

Caching a slow query makes it fast until the cache misses, at which point the slowness reappears at the worst moment. It also makes the underlying problem invisible.

The order is always: find the slow thing, understand why, fix it if you can, and cache what remains genuinely expensive.

What is worth caching

• Expensive aggregations that change infrequently
• Configuration and reference data
• Third-party API responses with a sensible lifetime
• Rendered fragments that are costly and change rarely
• Computed values with a clear invalidation trigger

Invalidation is the hard part

1. Decide when each cached item becomes stale, before caching it
2. Prefer event-based invalidation over time-based where correctness matters
3. Use short lifetimes where staleness is acceptable and invalidation is awkward
4. Never cache anything user-specific under a shared key

The classic bug is a cache keyed by question rather than by user, so one person sees another's data. It is easy to introduce and embarrassing to discover.

Cache layers

Know what happens when it is empty

A cold cache after a deployment or a restart means every request does the expensive work at once. On a busy system that can be enough to bring it down.

Either warm the cache after deployment, or make sure the uncached path is survivable. Discovering this during a restart at a busy moment is unpleasant.

Frequently asked questions