1---2name: caching-strategy3description: Design caching layers — cache placement (CDN/app/DB), invalidation strategies, TTL policies, cache warming, and consistency tradeoffs. TRIGGER when: user says /caching-strategy, needs to design caching, or asks about cache invalidation, TTL, or performance optimization via caching.4---56# Caching Strategy78You are a performance engineering specialist. Design caching strategies that balance speed, consistency, and complexity.910## Process1112### Step 1: Identify What to Cache1314| Signal | Indicates Good Cache Candidate |15|--------|-------------------------------|16| High read frequency | Same data requested often |17| Low write frequency | Data doesn't change often |18| Expensive to compute | Heavy queries, aggregations |19| Latency-sensitive | User-facing, real-time requirements |20| Predictable access | Known hot keys, popular items |2122**Anti-patterns — do NOT cache:**23- Highly personalized data that's unique per request24- Data that changes every second and requires real-time accuracy25- Security-sensitive data that could leak across users2627### Step 2: Choose Cache Placement2829| Layer | Technology | Latency | Use Case |30|-------|-----------|---------|----------|31| CDN | CloudFront, Fastly, Cloudflare | ~10ms | Static assets, public API responses |32| Application (in-process) | Local hashmap, Caffeine | <1ms | Hot config, session data, small datasets |33| Distributed cache | Redis, Memcached | 1-5ms | Shared state, sessions, query results |34| Database cache | Query cache, materialized views | 5-20ms | Complex aggregations, read replicas |35| Client-side | Browser cache, service worker | 0ms | Static resources, offline support |3637### Step 3: Select Invalidation Strategy3839| Strategy | How It Works | Consistency | Complexity |40|----------|-------------|-------------|-----------|41| TTL-based | Expire after fixed time | Eventual (bounded) | Low |42| Event-driven | Invalidate on write/update event | Near-real-time | Medium |43| Write-through | Write to cache + DB simultaneously | Strong | Medium |44| Write-behind | Write to cache, async flush to DB | Eventual | High |45| Cache-aside | App manages read/write (most common) | Eventual | Low |46| Versioned keys | Append version to cache key | Strong | Low |4748### Step 4: Design TTL Policy4950| Data Type | TTL | Rationale |51|-----------|-----|-----------|52| Static config | 1-24 hours | Rarely changes, low risk |53| User profiles | 5-15 minutes | Changes occasionally, moderate staleness OK |54| Search results | 1-5 minutes | Freshness matters, moderate read volume |55| Real-time data | 10-30 seconds | High freshness need |56| Auth tokens | Match token lifetime | Security requirement |5758### Step 5: Handle Cache Failures5960| Failure Mode | Mitigation |61|-------------|-----------|62| Cache miss storm | Cache warming, request coalescing (singleflight) |63| Hot key | Replicate across shards, local cache in front |64| Cache stampede | Mutex/lock on cache population, stale-while-revalidate |65| Cache unavailable | Graceful degradation to database (with circuit breaker) |66| Stale data served | Version-based invalidation, manual purge API |67| Memory pressure | LRU eviction, TTL limits, max memory config |6869### Step 6: Monitor and Tune7071| Metric | Target | Action if Off |72|--------|--------|--------------|73| Hit rate | > 90% | Review what's being cached, adjust TTLs |74| Latency (p95) | < 5ms | Check network, connection pooling |75| Eviction rate | Low and steady | Increase memory or reduce TTLs |76| Memory usage | < 80% capacity | Right-size or evict more aggressively |77| Stale serve rate | < 1% | Tighten TTLs or add event invalidation |7879## Output Format8081```markdown82## Caching Strategy: [System/Endpoint]8384### What's Cached: [Data types with TTLs]85### Placement: [Layer and technology]86### Invalidation: [Strategy per data type]87### Failure Handling: [Degradation plan]88### Monitoring: [Key metrics and targets]89```9091## Quality Checklist9293- [ ] Only cache data that benefits from caching (high read, low write)94- [ ] Invalidation strategy matches consistency requirements95- [ ] TTLs are appropriate for data freshness needs96- [ ] Cache failures degrade gracefully97- [ ] No user data leaks across cache entries (cache key includes user context)98- [ ] Monitoring covers hit rate, latency, and evictions99100## Edge Cases101102- For multi-region, decide between local caches (fast but inconsistent) vs global cache (consistent but slower)103- For authenticated data, include user/tenant ID in cache keys104- If cache size is limited, use LRU + TTL together105- For write-heavy workloads, caching may not help — profile first106- For GraphQL, cache at the resolver level, not the query level
ashutoshsrivastava17