Redis Caching Strategy Design Prompt

You are a senior SRE and Redis expert who has designed caching layers for high-QPS services.

I will provide:
- The data being cached and its read/write ratio
- The source of truth (SQL/NoSQL/API)
- Consistency and staleness requirements

Your job:

1. **Pick a caching pattern**:
   - Cache-aside (lazy): app reads cache, on miss reads DB, then `SET` with TTL. Simplest, most common.
   - Write-through: app writes cache and DB synchronously. Strong-ish consistency, higher write latency.
   - Write-behind (write-back): write cache, async flush to DB. Fast writes, risk of loss on crash.
2. **Set TTLs deliberately**:
   - Use `SET key val EX <seconds>` or `SETEX`. Never cache forever without an eviction plan.
   - Add jitter to TTLs (e.g. base ± 10%) to avoid synchronized expiry.
3. **Prevent cache stampede** (thundering herd on a hot key expiry):
   - Use a mutex lock (`SET lock NX EX 5`) so one worker rebuilds while others serve stale.
   - Or early/probabilistic recomputation before TTL elapses.
   - Or request coalescing / single-flight at the app layer.
4. **Handle cache penetration** (misses for keys that never exist):
   - Cache negative results with a short TTL, or use a Bloom filter.
5. **Key naming and namespacing**:
   - Use `svc:entity:id` conventions; version the prefix (`v2:user:123`) for easy invalidation.
6. **Invalidation strategy**:
   - Explicit `DEL`/`UNLINK` on write, TTL expiry, or key-versioning. Avoid `KEYS pattern*`.
7. **Serialization and size**:
   - JSON vs MsgPack vs protobuf; keep values small; consider hashes for partial reads.
8. **Measure hit ratio**:
   - `INFO stats` → `keyspace_hits` / `keyspace_misses`. Tune TTLs from real data.

Mark DESTRUCTIVE: `FLUSHALL`/`FLUSHDB` (wipes cache, mass DB stampede), `KEYS *` on prod (blocks the event loop), `DEBUG` commands, and `CONFIG SET maxmemory-policy noeviction` (writes start failing when full).

---

Data cached: [DESCRIBE]
Source of truth: [DESCRIBE]
Consistency needs: [DESCRIBE]

Why this prompt works

Most caching bugs are not about Redis commands — they are about the pattern. This prompt forces an explicit choice between cache-aside, write-through, and write-behind, then layers on the failure modes (stampede, penetration, stale reads) that break systems at scale. It anchors every decision to real commands and to the hit-ratio metrics that tell you whether the cache is even helping.

How to use it

1. State the read/write ratio — caching pays off for read-heavy workloads.
2. Name the source of truth so invalidation has a clear owner.
3. Declare your staleness budget — seconds of staleness allowed drives TTL and pattern.
4. Paste current key names and TTLs if a cache already exists.

Useful commands

# Hit ratio — the single most important cache metric
redis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses'

# Inspect a key's TTL and type
redis-cli TTL user:123
redis-cli TYPE user:123

# Cache-aside write with TTL and jitter (app sets EX ~ 300 +/- 30)
redis-cli SET user:123 '{"name":"Ada"}' EX 300

# Stampede lock: only the winner rebuilds
redis-cli SET lock:user:123 1 NX EX 5

# Safe key discovery (non-blocking, cursor-based)
redis-cli SCAN 0 MATCH 'user:*' COUNT 100

# Memory used by a single key
redis-cli MEMORY USAGE user:123

Example config

# redis.conf — cache node tuned for eviction, not persistence
maxmemory 4gb
maxmemory-policy allkeys-lru
# Disable RDB/AOF on a pure cache to save IO (data is rebuildable)
save ""
appendonly no
# Lazy free large deletes off the event loop
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes

Common findings this catches

• No TTL + noeviction → memory fills, writes rejected.
• Synchronized expiry → periodic latency spikes and DB stampede.
• KEYS in hot paths → event-loop stalls and timeouts.
• Low hit ratio → TTL too short or wrong keys cached.
• Stale reads after writes → missing invalidation on the write path.
• Cache penetration → repeated misses hammering the DB for nonexistent keys.

When to escalate

• Multi-region cache coherence — needs an architecture review.
• Write-behind with strict durability requirements — involve data engineering.
• Sustained low hit ratio despite tuning — revisit whether caching fits the access pattern.