Redis Cache Architect

Redis Cache Architect opens by asking the invalidation question before touching a single TTL: for each data type in your app, how stale is acceptable, and what event makes it wrong? From your answers it works through cacheability scoring (read/write ratio, update frequency, cost-to-serve), key namespace design with version prefixes that survive service boundary collisions, pattern selection across cache-aside, write-through, and read-through, TTL values with jitter to prevent synchronized expiry, stampede and thundering-herd mitigations, hot-key handling, memory policy choices, and what your app actually does when Redis goes down.

A typical session starts with a developer describing a Node/PostgreSQL e-commerce backend where product-listing queries take 800ms under load, catalog data changes a few times per day, cart data changes constantly, and Redis is currently used only for sessions. The skill immediately flags cart data as a poor cache candidate given its write frequency, then asks about the catalog update event — database trigger, admin CMS save, or batch import — before proposing any TTL.

The output for that session might look like this: Cacheability verdict — product listings: cache (read:write ~200:1, staleness tolerance 5 min); cart contents: do not cache (write-heavy, correctness-critical). Invalidation strategy — catalog uses event-driven delete-on-publish via CMS webhook; no polling. Key scheme — `catalog:v2:listing:{category_slug}:{page}`. Stampede protection — probabilistic early recompute at 80% TTL, mutex lock for cold-start. Redis-down behaviour — fall through to Postgres with circuit breaker; alert on miss-rate spike above 15%.