| name | caching-strategy-designer |
| description | Design caching layers so work is done once, not per request — HTTP/CDN caching, application-level caches (Redis/Memcached), computed-result caching, and cache-invalidation strategy. Use this skill whenever the user wants to add caching, asks why the same work is recomputed, designs a read-heavy system, or an audit skill (db-efficiency-audit, web-carbon-audit) flags uncached repeated work. Part of Lean Agentic AI Skills; emits a cache design plus lean-findings.json. |
Caching Strategy Designer
Advisor skill. Input: request patterns (read/write ratio, repetition, staleness tolerance per data type), current architecture. Output: cache design + lean-findings.json (findings = repeated work currently uncached).
Recomputation is the default waste of read-heavy systems: same query, same render, same API aggregation, per request. Every cache layer converts O(requests) work into O(changes) work — an E-reduction proportional to the hit rate.
Subject type: emit subject.type: "architecture" in findings.
Design ladder (outermost first — bytes not sent beat bytes served fast)
- HTTP caching headers — Cache-Control/ETag/Last-Modified on static assets and cacheable API GETs. Free infrastructure (the browser). Immutable+hashed filenames for assets → cache forever.
- CDN/edge — static assets always; HTML/API for anonymous traffic with short TTLs + stale-while-revalidate. Names E↓ (origin work) and often I-adjacent (edge closer to user, less transit).
- Application cache — Redis/Memcached for hot objects, session-adjacent data, expensive aggregations. Specify per entry: key schema, TTL, invalidation trigger, stampede protection (singleflight/lock or early-refresh) — stampedes turn cache expiry into an energy spike.
- Computed-result cache — memoize expensive pure functions, materialize expensive views/reports on change or schedule instead of on request.
- Client-side state — don't refetch what the page already has.
Per-layer specification (the design must include)
What's cached, keyed how, TTL and why, invalidation path (event-driven beats TTL guessing for correctness-sensitive data), expected hit-rate basis (measure repetition in a week of access logs — report the measured rate), and the metric that proves it (hit ratio dashboarded).
Trade-offs to always name
Staleness per data type (a price and a blog post have different budgets), invalidation complexity ("the two hard problems"), memory cost of the cache itself, cold-start behavior, personalization fragmenting hit rates.
Not this skill's job
LLM-specific caching (llm-cache-designer), query optimization (db-efficiency-audit).
