Agent skill · data analytics · jeremylongshore
implementing-database-caching
Process use when you need to implement multi-tier caching to improve
Why this skill is useful
Provides specific patterns and configurations for implementing multi-tier caching with Redis that the AI wouldn't reliably generate on its own.
What it needs
Requires docker, redis installed locally. About 4k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
Database Cache Layer Overview Implement multi-tier caching strategies using Redis, application-level in-memory caches, and query result caching to reduce database load and improve read latency. This skill covers cache-aside, write-through, and write-behind patterns with proper invalidation strategies, TTL configuration, and cache stampede prevention. Prerequisites Redis server (6.x+) available or Docker for running docker run redis:7-alpine redis-cli installed for cache inspection and debugging Application framework with Redis client library (ioredis, redis-py, Jedis, go-redis) Database query profiling data identifying read-heavy and slow queries Understanding of data freshness requirements (how stale can cached data be) Monitoring tools for cache hit rate and Redis memory usage Instructions 1. Profile database queries to identify caching candidates. Focus on queries that: execute more than 100 times per minute, take longer than 50ms, return data that changes less frequently than every 5 minutes, and produce results smaller than 1MB. Use pgstatstatements or MySQL slow query log. 2. Design the cache key schema with a consistent naming convention: service:entity:identifier:variant. Examples: app:user:12345:profile, app:products:category:electronics:page:1. Include a version prefix to enable bulk invalidation: v2:app:user:12345. 3. Implement the cache-aside pattern for read-heavy data: Check Redis first: GET app:user:12345:profile On cache miss: query database, then SET app:user:12345:profile <json> EX 3600 On data update: DEL app:user:12345:profile to invalidate Wrap in a helper function that abstracts cache-then-database logic 4. Configure TTL values based on data change frequency: Static reference data (countries, categories): TTL 24 hours or longer User profile data: TTL 15-60 minutes Product listings: TTL 5-15 minutes Session data: TTL matching session timeout Real-time data (inventory counts, prices): TTL 30-60 seconds or skip caching 5. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/implementing-database-caching