Design and implement caching strategies across all layers — in-memory, distributed (Redis/Memcached), CDN, HTTP cache headers, and application-level memoization
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Design and implement caching strategies across all layers — in-memory, distributed (Redis/Memcached), CDN, HTTP cache headers, and application-level memoization
["Resource or endpoint to cache","Current latency or load characteristics","Data freshness requirements (real-time, near-real-time, stale-ok)","Infrastructure available (Redis, Memcached, CDN provider, edge)"]
outputs
["Caching strategy document with layer recommendations","Implementation code for chosen cache layer(s)","Cache invalidation plan","TTL and eviction policy recommendations","Monitoring and hit-rate tracking guidance"]
["May add Redis or cache dependencies to project","May modify HTTP response headers","May add middleware or proxy configuration"]
Caching Strategies Skill
Purpose
Caching is the single highest-ROI performance optimization in most systems. This skill designs multi-layer caching strategies, implements them correctly, and — critically — plans cache invalidation so stale data does not become a silent bug.
Key Concepts
The Caching Pyramid (Top = Fastest, Bottom = Slowest)
Is it static content (images, JS, CSS)?
→ CDN + immutable cache headers
Is it per-user, session-scoped?
→ In-memory (server) or browser cache
Is it shared across users, read-heavy?
→ Redis / Memcached with cache-aside
Is it an expensive pure computation?
→ Memoization (in-process LRU)
Is it an API response with known TTL?
→ HTTP Cache-Control headers + stale-while-revalidate
Step 3: Implement
HTTP Cache Headers
// Next.js API route or middlewareexportfunctionGET(request: Request) {
const data = awaitfetchData();
returnResponse.json(data, {
headers: {
// Public: CDN can cache. max-age: browser TTL. s-maxage: CDN TTL.'Cache-Control': 'public, max-age=60, s-maxage=300, stale-while-revalidate=600',
// Vary ensures different cached versions per relevant header'Vary': 'Accept-Encoding, Authorization',
},
});
}
Cache-Control Cheat Sheet:
Directive
Meaning
public
Any cache (CDN, proxy) may store
private
Only browser may store
no-cache
Must revalidate before use (NOT "don't cache")
no-store
Truly never cache
max-age=N
Fresh for N seconds (browser)
s-maxage=N
Fresh for N seconds (shared/CDN cache)
stale-while-revalidate=N
Serve stale for N seconds while refreshing in background
// After a write operation, invalidate related cache keysasyncfunctionupdateUser(userId: string, data: UpdateUserData) {
const updated = await db.user.update({ where: { id: userId }, data });
// Invalidate all cache keys related to this userconst keysToInvalidate = [
`app:user:${userId}`,
`app:user-profile:${userId}`,
`app:user-posts:${userId}`,
];
awaitPromise.all(keysToInvalidate.map((key) => redis.del(key)));
// If using tag-based invalidation (Next.js)revalidateTag(`user-${userId}`);
return updated;
}
Pattern: Versioned Keys
// Instead of invalidating, bump a versionconst version = await redis.incr(`version:user:${userId}`);
const cacheKey = `user:${userId}:v${version}`;
// Old versions naturally expire via TTL
Step 5: Monitor Cache Health
Key metrics to track:
Hit Rate: Target > 90% for most caches
Miss Rate: Spikes indicate cold cache or invalidation storms
Eviction Rate: High evictions = cache is too small
Dogpiling — Multiple processes try to rebuild the same cache entry. Fix: Probabilistic early expiration or mutex.
Over-caching — Caching data that changes frequently, leading to stale reads. Fix: Measure read:write ratio first.
Key Explosion — Unique keys per request parameter combo. Fix: Normalize and limit key cardinality.
Examples
Example 1: E-commerce Product Page
Layer 1: CDN (Vercel Edge) — Cache full HTML for 60s, stale-while-revalidate 300s
Layer 2: Redis — Cache product data for 5 min, invalidate on admin update
Layer 3: DB query cache — Materialized view for price calculations, refresh every minute
Invalidation: Webhook from CMS triggers revalidateTag('product-{id}')
Example 2: User Dashboard (Personalized)
Layer 1: Browser — Cache-Control: private, max-age=0, must-revalidate (no shared cache)
Layer 2: Redis — Cache per-user dashboard data for 30s
Layer 3: In-memory — LRU cache for user preferences (small, rarely changes)
Invalidation: Write-through on user action, TTL expiry for background data
Example 3: Public API with Rate Limits
Layer 1: CDN — Cache GET responses for 10s with Vary: Authorization
Layer 2: Redis — Cache API responses per unique query hash for 60s
Rate limit: Use Redis INCR with TTL for sliding window rate limiting
Invalidation: Short TTLs only — no explicit invalidation needed
