Designs multi-layer caching – CDN, application, and database – choosing the pattern, TTL, and invalidation plan per data type, and produces a cache-decision table plus stampede protection.
Designs multi-layer caching - CDN, application, and database - choosing the pattern, TTL, and invalidation plan per data type, and produces a cache-decision table plus stampede protection. Use when someone asks "should I cache this", "Redis or CDN for this endpoint", "how do I invalidate this cache", "why is my cache hit rate so low", or is bolting Redis onto a slow service. Do NOT use for sizing or tuning database connection pools - use connection-pool-tuner instead - and do NOT use for frontend bundle, image, or Core Web Vitals work - use web-performance instead.This is the skill's description: the text your AI reads to decide when the skill applies.
caching-strategy/SKILL.md
---
name: Caching Strategy
description: Designs multi-layer caching - CDN, application, and database - choosing the pattern, TTL, and invalidation plan per data type, and produces a cache-decision table plus stampede protection. Use when someone asks "should I cache this", "Redis or CDN for this endpoint", "how do I invalidate this cache", "why is my cache hit rate so low", or is bolting Redis onto a slow service. Do NOT use for sizing or tuning database connection pools - use connection-pool-tuner instead - and do NOT use for frontend bundle, image, or Core Web Vitals work - use web-performance instead.
---
# Caching Strategy
A cache is a correctness liability you accept in exchange for latency, so every cache needs an explicit answer to "how stale can this be?" and "how does it get invalidated?" before it ships. The costly mistake this skill prevents is the write-only cache: a layer that adds a network hop and an invalidation bug surface while its hit rate quietly sits below 50 percent, making the system slower and wronger at the same time.
## Operating procedure
Work per data type, not per system - "cache the API" is not a decision, "cache the product listing for 60s at the CDN" is.
### Step 1: Gather inputs
Collect these for each candidate data type. If a number is an estimate, label it a guess and refine from production metrics later.
1. Read:write ratio. How many reads per write to the same key.
2. Recompute cost. Latency of a cache miss (DB query, computation, upstream call).
3. Staleness tolerance. How stale a value can be before it causes a user-visible or business-logic error. Get a number in seconds, not "pretty fresh".
4. Key cardinality and object size. Millions of small keys behave differently from thousands of megabyte blobs.
5. Whether the data is user-specific or shared.
### Step 2: Decide whether to cache at all
… load the full skill through Skill MeClick to play with sound.