Caching Strategy Template for Engineering Teams

For product catalog data, 90-95% is a good target. For user session data, 95%+ is typical because sessions are read far more than they are written. For search results, 60-80% is realistic because query diversity is high. A hit rate below 50% suggests the data is not a good caching candidate, the TTL is too short, or the key design is creating too many unique entries.

Use Redis when you need data structures beyond simple key-value (sorted sets, lists, hashes, pub/sub) or when you need persistence. Use Memcached for pure key-value caching where simplicity and multi-threaded performance matter. For most product teams, Redis is the default choice because its data structure support enables more caching patterns.

A cache stampede occurs when a popular key expires and hundreds of requests simultaneously hit the origin. Three mitigations: (1) Add jitter to TTLs so keys do not all expire at the same time. (2) Use a lock or single-flight pattern so only one request fetches from origin while others wait for the cache to be repopulated. (3) Use "stale-while-revalidate" to serve the expired value while a background process refreshes it.

PMs should care about the user-facing trade-offs. Caching makes data slightly stale. If a user updates their profile and the change takes 30 seconds to appear, that is a product decision, not just a technical one. PMs should define freshness requirements per data type (this template's Data Inventory section) and let engineering choose the caching implementation.

Cache warming pre-populates the cache before traffic hits cold instances. Run a warmup script that fetches the top 1,000 most-accessed keys from the origin and writes them to the cache. Alternatively, route a small percentage of traffic to new instances for 2-3 minutes before shifting full load. The [Load Testing Template](/templates) includes a warmup phase configuration for this purpose.