Redis Caching Skill
A practical playbook for adding Redis caching that actually cuts latency without
serving stale or inconsistent data. Examples lean on Spring Data Redis / common
clients, but the patterns (cache-aside, TTL discipline, stampede protection,
distributed locks) apply to any language.
Work in order: pick a strategy, set TTL + eviction, get invalidation
right (the hard part), protect against stampedes, then layer on data-structure
patterns (rate limiting, locks, sessions, leaderboards).
When to Use
- Adding a cache in front of a database or expensive computation
- Choosing between cache-aside, write-through, and write-behind
- Deciding TTLs, eviction policy, and keyspace naming
- Fixing stale reads or a cache-stampede / thundering-herd incident
- Implementing rate limiting, distributed locks, sessions, or leaderboards
The Workflow
flowchart LR
S[1. Strategy] --> T[2. TTL & Eviction]
T --> I[3. Invalidation]
I --> P[4. Stampede Protection]
P --> D[5. Data-Structure Patterns]
1. Strategy
Choose how reads and writes flow through the cache. Cache-aside is the default;
reach for write-through/write-behind only when you need them.
See Caching Strategies.
2. TTL & Eviction
Every cached key needs a TTL — caches are not source of truth. Match the eviction
policy (allkeys-lru, volatile-ttl, …) to your access pattern and memory budget.
See TTL & Eviction.
3. Invalidation
The hard part. Prefer short TTLs + write-time invalidation over clever schemes.
Decide between deleting vs. updating keys on write, and namespace keys for bulk busts.
See Invalidation.
4. Stampede Protection
When a hot key expires, concurrent misses can hammer the database. Defend with
locking/single-flight, jittered TTLs, or early recomputation.
See Stampede Protection.
5. Data-Structure Patterns
Redis is more than a cache: rate limiters, distributed locks, sessions, leaderboards,
and pub/sub — each maps to a specific data structure and command set.
See Data-Structure Patterns.
Quick Checklist
Reference Files
1---2name: redis-caching3description: Implementation playbook for using Redis as a cache and for common data-structure patterns. Use when asked to: add caching to a service, choose a caching strategy (cache-aside / write-through / write-behind), set TTLs and eviction, invalidate or warm a cache, implement rate limiting, a distributed lock, sessions, or a leaderboard. Triggers: "Redis", "cache", "caching", "cache-aside", "write-through", "write-behind", "TTL", "eviction", "LRU", "LFU", "cache invalidation", "cache stampede", "thundering herd", "rate limit", "distributed lock", "Redlock", "session store", "leaderboard", "pub/sub", "Lettuce", "Jedis", "@Cacheable".4---56# Redis Caching Skill78A practical playbook for adding Redis caching that actually cuts latency without9serving stale or inconsistent data. Examples lean on Spring Data Redis / common10clients, but the patterns (cache-aside, TTL discipline, stampede protection,11distributed locks) apply to any language.1213Work in order: pick a **strategy**, set **TTL + eviction**, get **invalidation**14right (the hard part), protect against **stampedes**, then layer on **data-structure15patterns** (rate limiting, locks, sessions, leaderboards).1617---1819## When to Use2021- Adding a cache in front of a database or expensive computation22- Choosing between cache-aside, write-through, and write-behind23- Deciding TTLs, eviction policy, and keyspace naming24- Fixing stale reads or a cache-stampede / thundering-herd incident25- Implementing rate limiting, distributed locks, sessions, or leaderboards2627---2829## The Workflow3031```mermaid32flowchart LR33 S[1. Strategy] --> T[2. TTL & Eviction]34 T --> I[3. Invalidation]35 I --> P[4. Stampede Protection]36 P --> D[5. Data-Structure Patterns]37```3839---4041### 1. Strategy4243Choose how reads and writes flow through the cache. **Cache-aside** is the default;44reach for write-through/write-behind only when you need them.4546See [Caching Strategies](./references/strategies.md).4748---4950### 2. TTL & Eviction5152Every cached key needs a TTL — caches are not source of truth. Match the eviction53policy (`allkeys-lru`, `volatile-ttl`, …) to your access pattern and memory budget.5455See [TTL & Eviction](./references/ttl-eviction.md).5657---5859### 3. Invalidation6061The hard part. Prefer short TTLs + write-time invalidation over clever schemes.62Decide between deleting vs. updating keys on write, and namespace keys for bulk busts.6364See [Invalidation](./references/invalidation.md).6566---6768### 4. Stampede Protection6970When a hot key expires, concurrent misses can hammer the database. Defend with71locking/single-flight, jittered TTLs, or early recomputation.7273See [Stampede Protection](./references/stampede.md).7475---7677### 5. Data-Structure Patterns7879Redis is more than a cache: rate limiters, distributed locks, sessions, leaderboards,80and pub/sub — each maps to a specific data structure and command set.8182See [Data-Structure Patterns](./references/patterns.md).8384---8586## Quick Checklist8788- [ ] Strategy chosen (cache-aside by default; justify write-through/behind)89- [ ] Every key has a TTL; no unbounded keys90- [ ] Eviction policy matches access pattern + memory budget91- [ ] Invalidation defined at write time; keys namespaced for bulk busts92- [ ] Stampede protection on hot keys (lock / jitter / early refresh)93- [ ] Null/negative results cached briefly to prevent penetration94- [ ] Distributed locks have a TTL + ownership token (safe release)95- [ ] Keyspace naming convention documented (`entity:id:field`)9697---9899## Reference Files100101- [Caching Strategies](./references/strategies.md)102- [TTL & Eviction](./references/ttl-eviction.md)103- [Invalidation](./references/invalidation.md)104- [Stampede Protection](./references/stampede.md)105- [Data-Structure Patterns](./references/patterns.md)
AmitSharma1994