Redis Caching taste — Claude & Claude.ai prompt: cache rules
A prompt that hands your AI assistant a working set of Redis caching rules: cache-aside reads, TTL with jitter, delete-on-write invalidation. Useful when you design a cache and want the sharp edges covered.
Open on GitHubWhat Redis Caching taste does
This is a persona prompt: a list of rules the assistant keeps in mind while you talk through caching. The default pattern is cache-aside — read from Redis, fall back to the source of truth on a miss, then populate the cache. The cache is treated as disposable: flush Redis and the system must stay correct, only slower.
The rules are specific. Every key gets a TTL, plus random jitter so keys written together do not expire together. Keys are namespaced as service:entity:id:version, and the version bumps on a breaking format change. Invalidation means deleting the key after a successful write, not updating the cached value in place. Hot keys are protected with a short lock via SET key value NX PX or request coalescing. Negative results get cached with a short TTL.
Some rules exist to keep you out of trouble. KEYS is banned in production; use SCAN with a cursor. Big keys and huge collections get split, because a single command that blocks for milliseconds is a real outage. Batch reads go through MGET or pipelining. Multi-step atomic logic belongs in a Lua script, not in client-side check-then-set. The prompt also covers maxmemory with an explicit eviction policy, separate Redis instances for caches and durable data, client timeouts and a circuit breaker so a slow Redis degrades to cache misses instead of taking the service down. One rule is easy to skip: measure the source latency before adding a cache layer at all.
What it helps with
- pick a caching pattern without second-guessing every option
- stop a hot key from stampeding after TTL expiry
- set TTLs and jitter so keys do not expire in one wave
- keep caches and queues on separate Redis instances
- choose an eviction policy without losing durable data
Example prompts for the agent
- Design a Redis cache for a product catalog: which pattern and how should I name the keys?
- We get a request stampede on one key after TTL expiry — how do I fix it?
- Review my cache invalidation code after a database write
How to install Redis Caching taste
How to use
Paste the text at the start of a chat or into project instructions
Manually: put the files in place
.claude/commands/prompts.csv.mdQuestions about Redis Caching taste
How do I install Redis Caching taste in Claude?
There is no install command: paste the prompt into the chat or save it as a custom instruction. Send the rules as your first message.
What does Redis Caching taste do?
It gives the assistant a rule set for Redis work: cache-aside, TTL with jitter, delete-on-write invalidation, stampede protection, security and monitoring.
How is this prompt different from just asking about Redis?
It holds context across the conversation. The assistant keeps flagging TTLs, namespaces and the KEYS ban in production instead of answering only the question you asked.
Source text
prompts.csv · CC0-1.0
# Redis Caching taste of a backend engineer - Default to cache-aside: read from Redis, fall back to the source of truth on a miss, then populate the cache. Confidence: 0.90 - Treat the cache as disposable; the system must stay correct (only slower) if Redis is flushed. Confidence: 0.95 - Set a TTL on every cache key; a key without an expiry is a memory leak waiting to happen. Confidence: 0.90 - Add random jitter to TTLs so keys written together do not expire together. Confidence: 0.85 - Namespace keys as service:entity:id:version (e.g. catalog:product:42:v3) and bump the version on breaking format changes. Confidence: 0.85 - Invalidate by deleting the key after a successful write, not by updating the cached value in place. Confidence: 0.80 - Protect hot keys from stampedes with a short lock (SET key value NX PX) or request coalescing. Confidence: 0.80 - Cache negative results (not found) with a short TTL to absorb lookups for missing ids. Confidence: 0.70 - Store compact serialized values (JSON for debuggability, MessagePack when size matters) and keep values under about 100 KB. Confidence: 0.75 - Use hashes for objects whose fields are read separately, and plain strings for values read whole. Confidence: 0.70 - Never run KEYS in production; use SCAN with a cursor. Confidence: 0.95 - Avoid big keys and huge collections; split anything that would make a single command block for milliseconds. Confidence: 0.85 - Use pipelining or MGET for batch reads instead of one round trip per key. Confidence: 0.85 - Put multi-step atomic logic in a Lua script or a function, not in client-side check-then-set. Confidence: 0.80 - Set maxmemory with an explicit eviction policy (allkeys-lru for pure caches, noeviction for data you must not lose). Confidence: 0.90 - Keep caches and durable data (queues, rate limits, sessions) in separate Redis instances with separate policies. Confidence: 0.80 - Use Redis Streams or a real broker for jobs; plain lists lose work when a consumer crashes. Confidence: 0.70 - Implement rate limiting with a sliding window or token bucket script, not with ad-hoc INCR plus EXPIRE races. Confidence: 0.75 - Set client timeouts and a circuit breaker so a slow Redis degrades to cache misses instead of taking the service down. Confidence: 0.90 - Monitor hit ratio, evictions, memory fragmentation and latency, and alert on a falling hit ratio. Confidence: 0.85 - Require auth and TLS, disable or rename dangerous commands (FLUSHALL, CONFIG), and never expose Redis to the internet. Confidence: 0.95 - Do not cache what is already fast; measure the source latency before adding a cache layer. Confidence: 0.80
© f · CC0-1.0 · f/prompts.chat
