Redis Design and Usage Assistant

Problem

Cache, lock, rate-limit, and queue designs often start with commands first and constraints later, causing inconsistent key names, missing TTLs, big keys, unsafe use of KEYS *, and cluster slot mismatches. This skill turns Redis design into a checkable engineering path.

How it works

It identifies intent first, such as cache design, data structure selection, key naming, TTL, locks, rate limiting, or queues, then works through a path:

• Selection: compares String, Hash, List, Set, ZSet, Stream, Bitmap, and HyperLogLog for fit.
• Naming and TTL: checks business:entity:id style names, colon separators, abbreviations, unsafe characters, and TTL requirements.
• Patterns: maps Cache-Aside, Write-Through, and Write-Behind, then separates penetration, breakdown, and avalanche fixes.
• Hard limits: prefers SCAN over KEYS *, requires lock timeout and atomic release, and keeps Pipeline batches to 500 commands or fewer.

It can also load files under references/ for design details, usage guidance, best practices, and version notes.

Boundaries

This is a design and usage guardrail, not a substitute for environment validation, capacity planning, or operations strategy. For 7.0 or 8.0 features, it checks loaded version references for deprecations and new capabilities; production use still needs validation against consistency, QPS, data scale, and business context.