| name | caching-strategy-review |
| enabled | true |
| description | Use when performing caching strategy review — reviews and designs caching
strategies for services, evaluating cache placement, invalidation approaches,
consistency trade-offs, and capacity planning. This template helps teams make
informed decisions about what to cache, where to cache it, and how to handle
cache lifecycle management.
|
| required_connections | [{"prefix":"monitoring","label":"Monitoring Platform"}] |
| config_fields | [{"key":"service_name","label":"Service Name","required":true,"placeholder":"e.g., product-catalog-api"},{"key":"cache_technology","label":"Cache Technology","required":false,"placeholder":"e.g., Redis, Memcached, CDN"}] |
| features | ["CACHING","PERFORMANCE","ARCHITECTURE"] |
Caching Strategy Review
Phase 1: Current State Assessment
Document the existing caching setup (or lack thereof).
Phase 2: Cache Candidacy Analysis
Evaluate which data should be cached.
| Data | Read Frequency | Write Frequency | Read:Write Ratio | Staleness Tolerance | Size per Entry | Cache Candidate |
|---|
| High/Med/Low | High/Med/Low | | Seconds/Minutes/Hours | | Y/N |
Decision Matrix — Cache Candidacy:
| Criteria | Strong Candidate | Weak Candidate |
|---|
| Read:Write ratio | >10:1 | <2:1 |
| Staleness tolerance | Minutes to hours | Real-time required |
| Computation cost | Expensive queries or aggregations | Simple key lookups |
| Data size | Fits in memory budget | Too large for cache tier |
| Access pattern | Hot subset, power law distribution | Uniform random access |
Phase 3: Cache Architecture Design
Cache Placement:
Cache Strategy Selection:
| Pattern | When to Use | Trade-offs |
|---|
| Cache-aside (lazy loading) | General purpose, read-heavy | Cache miss penalty, potential stale data |
| Write-through | Need strong consistency | Write latency increase |
| Write-behind | Write-heavy, eventual consistency OK | Complexity, data loss risk |
| Read-through | Simplify application code | Cache dependency for all reads |
| Refresh-ahead | Predictable access patterns | Wasted refreshes for unused data |
Phase 4: Invalidation Strategy
Consistency Analysis:
Phase 5: Capacity and Resilience
Counter-Rationalizations
| Shortcut | Counter | Why |
|---|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |
Output Format
Summary
- Service: ___
- Cache technology: ___
- Strategy: ___
- Expected hit ratio: ___%
- Expected latency improvement: ___
- Memory budget: ___
Action Items