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
- Decide when each cached item becomes stale, before caching it
- Prefer event-based invalidation over time-based where correctness matters
- Use short lifetimes where staleness is acceptable and invalidation is awkward
- 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
| Layer | Use for |
|---|---|
| Application cache | Computed values, configuration |
| Query result cache | Expensive aggregations |
| Fragment cache | Costly rendered sections |
| Full page cache | Public pages only |
| HTTP cache headers | Static assets |
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.