caching-strategy

Guides cache backend selection, TTL design, key naming, and invalidation contracts for Node.js services.

Updated Dec 24, 2025
One-click install
npx skills add https://github.com/JoyJoin-Tech-Limited/JoyJoin_app_v0.1 --skill caching-strategy-joyjoin-tech-limited
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: caching-strategy
Source: https://github.com/JoyJoin-Tech-Limited/JoyJoin_app_v0.1/tree/main/.github/skills/caching-strategy
Command: npx skills add https://github.com/JoyJoin-Tech-Limited/JoyJoin_app_v0.1 --skill caching-strategy-joyjoin-tech-limited

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Choosing the wrong cache backend or missing invalidation logic causes stale data, unbounded memory growth, and rate limits that break under horizontal scaling. This Skill provides a decision framework for matching cache backends to durability needs and enforcing consistent TTL, key naming, and invalidation contracts. ## Core Features & Use Cases - Backend Selection Guidance: Maps durability needs to the right store — in-memory Map for ephemeral run-local deduplication, node-cache for process-local TTL, PostgreSQL for durable shared data, and Redis as the planned distributed target. - TTL and Key Naming Standards: Defines TTL guidelines per data type (7 days for expensive LLM output, 5 minutes for pair scores) and collision-resistant key naming patterns. - Invalidation and Scaling Guardrails: Documents invalidation contracts wired to write paths and flags in-memory caches with TODO(redis) markers for horizontal-scaling readiness. - Use Case: When a user reports stale match explanations after a profile update, use this Skill to trace the invalidation contract and fix substring-based cache deletion that misses roster-hash keys. ## Quick Start Ask the AI to review the caching approach for a new feature, for example: add caching for generated event themes with the right backend, TTL, and invalidation on roster changes.

Frequently Asked Questions about caching-strategy

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I choose between in-memory cache, node-cache, and Redis?▼

Match the backend to durability needs: in-memory Map for ephemeral run-local deduplication, node-cache for process-local TTL, PostgreSQL for durable shared data like sessions, and Redis for distributed caches that must survive horizontal scaling across instances.

What TTL should I use for cached API or AI data?▼

Use 7 days for expensive LLM-generated output, 1 hour for cheap classification, 5 minutes for pair scores tied to profile-update events, and 7 days for sessions via connect-pg-simple. Run-local caches are garbage-collected when the function returns.

Why does my rate limiter reset on every deploy?▼

The rate limiter uses an in-memory Map, which is process-local and cleared on restart. Mark it with a TODO(redis) comment and plan migration to a shared store like Redis for persistence across deploys and instances.

Why do users share one rate-limit key behind a proxy?▼

A misconfigured Express trust proxy setting causes all users to appear under one IP address, so the rate limiter keys everyone to the same bucket. Verify the trust proxy setting behind your load balancer.

When should I not use a caching strategy skill?▼

Avoid it for database query optimization, AI prompt caching or LLM output reuse, and frontend asset caching. Those belong to database architecture, LLM runtime integration, and frontend performance workflows respectively.