Caching Strategist

When to use

Use this skill when a system is too slow or too expensive at scale, when designing a new read-heavy service, when cache invalidation bugs are causing stale data, or when planning a performance optimization initiative. Caching done wrong causes worse problems than no cache (stale data, cache stampedes, consistency bugs). Trigger when the user mentions caching strategy, cache invalidation, CDN config, Redis design, cache stampede, or performance optimization.

Inputs to gather

• The read/write ratio of the data being cached
• Latency requirements and current bottlenecks (DB CPU, network, compute)
• Data volatility: how often the source data changes
• Consistency requirements: strict, eventual acceptable, stale tolerances
• The request distribution: are there hot keys or long-tail access
• Existing cache infrastructure (Redis, Memcached, CDN, CDN provider)
• The application's transaction and write patterns (writes that must invalidate cache)
• Deployment topology (single region, multi-region, edge)

Procedure

1. Identify what is actually worth caching. Cache only data that is read frequently relative to how often it changes, that is expensive to compute or fetch, and where staleness is tolerable to the degree the cache allows. Caching write-heavy or low-value data adds complexity without benefit. Measure before caching — confirm the source is the bottleneck.
2. Choose the cache layer by latency budget. Browser/edge cache for static assets and public responses (sub-10ms). CDN for geographically distributed static and cacheable dynamic content. Application cache (in-process or Redis) for computed or database-derived data (sub-1ms in-process, ~1ms Redis). Database cache for query results (materialized views, query cache). Place the cache as close to the user as the data's privacy and volatility allow.
3. Define the cache key scheme carefully. Keys must uniquely identify the cached value including all inputs that affect it (entity id, version, locale, user-scope if personalized). A key that omits a varying input returns the wrong user's data. Use a versioned key prefix (v2:user:123) so you can invalidate the entire cache on a deploy by bumping the version.
4. Choose the right invalidation strategy per cache. TTL-based for eventually-consistent data (set the TTL to the max acceptable staleness). Write-through (invalidate on write) for data that must be fresh. Event-driven invalidation (the write publishes an event; subscribers delete the key) for distributed systems where direct invalidation is racy. Tag/group-based invalidation when one write affects many keys. Pick the weakest strategy that meets the consistency requirement — stronger invalidation is more complex and more bug-prone.
5. Prevent cache stampedes. When a hot key expires, many requests miss simultaneously and all hit the source. Use one of: probabilistic early expiration (refresh slightly before TTL), mutex/lock on miss (one request computes, others wait), or request coalescing. Without protection, a popular key expiry becomes a thundering herd.
6. Handle cache failure gracefully. The cache will go down — design so the system degrades to the source of truth with higher latency, not to errors. Never make the cache the system of record without a persistence/durability plan. Set timeouts on cache reads so a slow cache doesn't cascade into request timeouts.
7. Measure hit rate, latency, and error rate per cache. A cache with a low hit rate isn't earning its complexity. Track hit/miss ratio, eviction rate, memory usage, and the p99 latency of cache reads vs source reads. A high miss rate means the TTL is too short, the key space is too large for the memory, or the data isn't actually reusable — diagnose rather than throw more memory at it.
8. Beware of consistency pitfalls in multi-layer caches. When the same data lives in browser, CDN, app, and DB caches, invalidation must propagate through all layers or you get stale data at one layer after a write. Document the per-layer invalidation path and test it. For multi-region setups, replication lag between cache regions can serve stale data — decide whether regions are eventually-consistent or coordinate.
9. Cache computed results, not just raw data. Caching an API response, a rendered fragment, or a computed aggregate often yields bigger wins than caching the underlying rows, because you skip the compute as well as the I/O. Identify the expensive transforms and cache their outputs.

Output format

A caching design document with: the data-to-cache inventory (what, why, hit-rate justification), the per-layer cache placement diagram, the key scheme with versioning, the invalidation strategy per cache (TTL, write-through, event-driven), the stampede protection mechanism, the failure/degradation plan, and the observability metrics (hit rate, latency, eviction).

Common pitfalls

• Caching write-heavy or rarely-read data, adding complexity with no benefit.
• Omitting a varying input (locale, user scope) from the cache key, returning the wrong user's data.
• Invalidating only one layer when data is cached at multiple, serving stale data from the un-invalidated layer.
• No stampede protection, so a hot key expiry triggers a thundering herd on the source.
• Making the cache the system of record, then losing data when the cache is evicted or crashes.
• Setting a TTL with no measurement of hit rate, so the cache silently misses constantly and earns nothing.