Redis prompts should begin with the role Redis plays. A cache of public article summaries has a different correctness boundary from a session record or a coordination lock. If an agent treats every use as a disposable cache, it may propose a fallback that changes application behavior. This collection focuses on cached reads: key boundaries, freshness, invalidation and what happens when the cache is unavailable.
Describe the source of truth and freshness rule
Provide key construction code, cached value shape, read path and all write or invalidation paths. State how stale a result may be and whether two users can ever share it. Include the client version and deployment environment. Do not paste connection strings into a reusable prompt; configuration names and sanitized topology are enough for most reviews.
Redis documents expiration behavior in the EXPIRE reference. Verify how the operations your code uses interact with expiration. Treat the TTL as one part of a freshness design, alongside key selection, update order and the authoritative read.
Review keys for collisions and private data mixing
A key must distinguish every dimension that changes the result. That can include tenant, locale, permission scope or the version of a derived format. Ask for concrete pairs of requests that would currently collide. This makes a review more useful than a recommendation to add a long prefix to every key.
Audit Redis keys in {{cache_module}} for {{cached_resource}}.
List the inputs that determine each value and compare them with the key.
Construct two requests that should differ but could collide, including
users A and B where relevant. Propose the smallest key change and a
transition plan for old entries. Preserve the authoritative data source.
Trace invalidation through concurrent writes
A cache can become stale immediately after an invalidation if another reader refills it from old data. Ask the agent to build a timeline with two readers and a writer. Provide the existing ordering and any version or timestamp field. Choose a repair only after deciding which freshness guarantee the product actually needs.
Review cache invalidation for {{write_operation}}.
Code: {{read_and_write_paths}}. Freshness requirement: {{freshness_rule}}.
Build a concurrent timeline showing read, write, invalidation and refill.
Identify a stale-value race if one exists. Compare feasible repairs and
add a focused concurrency test using controlled steps rather than sleeps.
Explain the remaining consistency tradeoff.
Define outage behavior and bound retries
A cache outage should have an intentional result. A fallback read may overload the source if every instance retries at once. Ask the agent to consider timeouts, concurrency and the response a person receives. Separate a cache miss from a connection failure so useful operational evidence is not hidden behind one empty result.
Plan Redis failure behavior for {{request_path}}.
Redis role: {{role}}. Source capacity: {{source_capacity}}.
Review timeouts, retries and fallback reads. Define the outcome for a miss,
slow cache and unavailable cache. Propose bounded behavior and metrics.
Do not silently fail open if Redis enforces a correctness requirement.
Test recovery as well as the outage itself.
Check the result against a realistic workload
Measure hit rate, latency and source load together. A higher hit rate can still be wrong if the cached result is stale or belongs to another scope. Validate cold starts, changed data and the removal of old key formats. Record how test conditions differ from production traffic.
Save the approved Redis prompt in Kipt with variables for module, freshness and workload. For database-side query evidence, use the PostgreSQL prompts before assuming a cache is the best first improvement.