spb/ultra-sharp-agent-skills Public

1---2name: caching-strategies3description: Designs application-level caching — cache-aside pattern, key naming, TTL policy, invalidation strategy, and stampede protection with Redis or in-process caches. Use when the user asks to add a cache, cache API responses or query results, speed up repeated reads, fix stale-cache or cache-invalidation bugs, or prevent cache stampedes. Do not use for HTTP/CDN edge caching configuration or for database query and index tuning.4---56<!--7Author: Simon-Pierre Boucher8Contact: contact@spboucher.ai9-->1011# Caching Strategies1213## When to use / when NOT to use14- **Use for:** adding or reviewing application caches (Redis, Memcached, in-process): what to cache, key design, TTLs, invalidation, failure behavior.15- **Do NOT use for:** CDN/`Cache-Control` edge configuration, database tuning (→ db-skills/optimizing-sql-performance), or memoizing pure functions in code.1617## Core rules18191. **Measure before caching.** Cache only reads that are demonstrably hot AND expensive; record the baseline latency and expected hit rate first. A cache below ~80% hit rate usually adds complexity for nothing.202. **Cache-aside is the default pattern:** read cache → miss → read origin → write cache with TTL. Write-through/write-behind only when a measured write-path need exists.213. **Every key has a TTL — no immortal keys.** TTL is the invalidation of last resort; without it, every bug becomes permanent.22   - ✅ `SETEX product:v1:42 300 …`23   - ❌ `SET product:42 …` (lives until someone remembers it exists)244. **Choose the invalidation strategy per data class, at design time:**25   - tolerates staleness → **TTL-only** (pick the tolerance as the TTL)26   - must reflect writes → **purge/update on write** (delete the key in the write path)27   - broad derived data → **versioned keys** (bump `v` in the key; old entries age out)28   Mixing strategies ad hoc is how stale-forever bugs are born.295. **Key schema is part of the design:** `entity:version:id[:variant]`, e.g. `product:v2:42:fr`. Every dimension that changes the value appears in the key — locale, currency, role.306. **Never serve one user's data from a shared key.** Per-user data gets the user ID in the key; better, don't cache authorization decisions at all.31   - ❌ `GET profile:current` — whoever primed it wins327. **Protect against stampedes:** jitter TTLs (±10%) so keys don't expire in sync, and use a single-flight lock so one process rebuilds a hot key while others serve slightly-stale or wait.338. **Cache down ≠ site down.** Wrap cache calls with a short timeout (~50 ms) and fall through to origin on any cache error; a cache outage becomes a latency event, not an availability event.3435## Workflow36371. Identify the hot, expensive read; record baseline latency and expected hit rate.382. Classify its data (staleness tolerance) and pick the invalidation strategy from rule 4.393. Define the key schema and TTL (+ jitter); implement cache-aside with origin fallback on cache errors.404. Add hit/miss metrics per key family.415. **Validate:** write to the origin and confirm the read path reflects it within the chosen tolerance; kill the cache and confirm requests still succeed from origin; check hit rate after a warm-up period against the target.4243## Edge cases & failure modes44- **Caching negative results** (not-found) — allowed with a SHORT TTL (~30 s) to absorb miss storms, but must be purged on create.45- **Large values** (>100 KB in Redis) — compress or split; big values evict everything else.46- **Cold start after deploy/flush** — expect an origin load spike; single-flight (rule 7) is what keeps it survivable.47- **Two caches for one datum** (in-process + Redis) — layered TTLs multiply staleness; keep the in-process layer very short (~1–5 s).4849## References50Snippets for single-flight, jitter, and key-schema helpers: see [references/patterns.md](references/patterns.md).51