Agent skill · software engineering · erichowens
caching-strategies
Design multi-tier caching architectures for web applications — cache-aside vs write-through vs write-behind, TTL design, cache invalidation, Redis patterns, CDN configuration, browser caching,
Why this skill is useful
Provides specific Redis caching patterns and multi-tier architecture strategies that the AI wouldn't reliably generate on its own.
What it needs
Requires redis installed locally. About 7k tokens when loaded. Last updated 2026-07-14. 180 stars on the source repository.
What this skill does
Caching Strategies Caching is the most commonly misapplied performance technique. The failure mode is not "cache too little" — it is "cache without an invalidation strategy and then discover the problem in production six months later when users complain about stale data that you cannot explain." When to Use ✅ Use for: Choosing which caching pattern fits a use case (cache-aside, write-through, write-behind) Designing TTL values for different data freshness requirements Implementing Redis caching patterns: sorted sets, pub/sub invalidation, Lua scripts Configuring Cache-Control headers, ETags, and CDN behavior Preventing cache stampedes via locking, probabilistic early expiry, or background refresh Cache warming strategies for cold-start scenarios Multi-tier cache design (in-memory L1, Redis L2, CDN L3) ❌ NOT for: Database-internal query plan caching (handled by the database) Python functools.lrucache / JavaScript memoize utilities (pure function memoization) CPU branch prediction or hardware cache tuning Session storage (use dedicated session skill) --- Which Caching Pattern? --- Multi-Tier Cache Architecture Tier Technology Latency Capacity Shared? --- --- --- --- --- L1: In-process Node.js Map, Python dict, LRU-cache ~0ms Small (MB) No — per instance L2: Distributed Redis, Memcached 1-5ms Large (GB) Yes — all instances L3: Edge/CDN Cloudflare, Fastly, CloudFront 10-100ms Massive Yes — globally Rule: Data mutates in one place first. Invalidation flows outward: DB → Redis → CDN. Never skip tiers in invalidation. --- Cache-Aside Pattern (Most Common) Application manages cache explicitly. On read: check cache, if miss fetch from DB, populate cache, return. On write: update DB, delete cache entry. When invalidation deletes vs overwrites: Delete is almost always correct. Overwriting in cache after a write creates a race: another request may have fetched the old value between your DB write and your cache write. Delete forces the next reader to fetch fresh. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills erichowens/caching-strategies