Caching Strategy

Steps:

Choose the appropriate caching pattern:

Default recommendation: Cache-Aside (simplest, most predictable).

3. Implementation ⚡ (Power Mode)

Steps:

1. Add Redis/Memcached client to the project.
2. Implement the chosen pattern with:
   • Key naming convention: {service}:{entity}:{id} or {service}:{query-hash}.
   • TTL (start with 5 minutes, tune based on staleness tolerance).
   • Serialization format (JSON or MessagePack).
3. Add cache-hit/miss metrics.

4. Invalidation Strategy ⚡ (Power Mode)

Steps:

1. Define invalidation triggers (entity update, delete, TTL expiry).
2. Implement pattern:
   • TTL-based: Set expiry on every key.
   • Event-based: Invalidate on write (pub/sub or after-commit hook).
   • Tag-based: Group related keys, invalidate by tag.
3. Handle thundering herd (cache stampede): use lock/singleflight.

5. Multi-Layer Cache Topology 🌿 (Eco Mode)

Steps:

1. Design a layered caching architecture where each layer trades latency for capacity:

   Layer	Technology	Latency	Capacity	Scope
   L1	In-process (LRU)	<1ms	Small (bounded by heap)	Per-instance
   L2	Shared distributed (Redis/Memcached)	1-5ms	Medium (cluster memory)	Cross-instance
   L3	Edge/CDN	5-50ms	Large (global)	Public content only

2. Read path: check L1 → miss? check L2 → miss? check L3 → miss? query origin. Nano: Cache Promotion — on L2 or L3 hit, promote the entry to L1 for faster subsequent access.

3. Write/invalidation path: Nano: Cross-Layer Invalidation — a write invalidates L1 immediately (local), then L2 (broadcast/pub-sub), then L3 (purge API). Invalidation cascades top-down.

4. Decision criteria for layer selection:

   Need	Recommended layers
   Ultra-low latency, single instance	L1 only
   Shared across instances, moderate latency	L1 + L2
   Public content, global distribution	L1 + L2 + L3
   Cost-sensitive, moderate traffic	L2 only (skip L1 overhead)

5. Monitor per-layer hit rates. If L1 hit rate < 50%, the L1 cache is too small or the workload isn't suitable for in-process caching.

Outputs

Scope

In Scope

• Identifying cacheable read paths and selecting appropriate caching patterns.
• Configuring cache clients (Redis, Memcached, in-memory) and connection settings.
• Implementing cache-aside, write-through, write-behind, and read-through patterns.
• Designing key naming conventions, TTL policies, and serialization formats.
• Implementing invalidation strategies (TTL, event-based, tag-based).
• Adding cache-hit/miss metrics and monitoring instrumentation.
• Handling cache stampede / thundering herd with locking or singleflight.

Out of Scope

• Provisioning or operating cache infrastructure (Redis clusters, Memcached nodes).
• Application-level business logic changes unrelated to caching.
• Database schema modifications (see database-design or db-tuning).
• CDN or edge-cache configuration (network-level caching).
• Session storage design — use dedicated session management patterns instead.

Guardrails

• Never cache writes or mutation responses; only cache idempotent read paths.
• Always set a TTL on every cache key — unbounded keys cause memory exhaustion.
• Preview all code diffs before applying; revert if tests fail after changes.
• Never store secrets, tokens, or PII in cache without encryption-at-rest.
• Do not introduce caching for paths with fewer than 100 req/min unless latency is critical.
• Run existing test suites after adding caching to verify no behavioral regression.
• Never bypass existing access-control checks by serving cached responses to unauthorized users.
• Log cache invalidation events to prevent silent stale-data bugs.

Ask-When-Ambiguous

Triggers

• Staleness tolerance is not specified by the caller.
• Multiple caching patterns could apply to the same data path.
• The target environment's cache infrastructure (Redis vs. Memcached vs. in-memory) is unknown.
• Data involves user-specific content that may require per-user key segmentation.
• Write frequency is high enough that invalidation overhead may negate caching benefit.

Question Templates

• "What staleness tolerance is acceptable for {entity}? (e.g., 30s, 5m, 1h)"
• "Which cache backend is available in this environment — Redis, Memcached, or in-process only?"
• "Should cached data be segmented per-user/tenant, or is it shared across all users?"
• "Are there existing pub/sub or event-bus mechanisms available for event-based invalidation?"
• "Is there a hard memory budget for the cache layer?"

Decision Criteria

Success Criteria

• Cache-hit ratio for targeted paths exceeds 80% under normal load.
• p95 latency for cached endpoints drops by at least 40% compared to baseline.
• No stale data served beyond the configured TTL window.
• Cache-miss path still returns correct results (cache is not a single point of failure).
• Cache-hit/miss metrics are emitted and visible in the monitoring dashboard.
• All existing tests pass after caching is introduced.
• Key naming convention is documented and consistently applied.
• Invalidation triggers fire correctly on entity create/update/delete.

Failure Modes

Audit Log

Each invocation of the Caching Strategy skill records the following timestamped entries in the scratchpad:

• [YYYY-MM-DDTHH:MM:SSZ] CACHE_SKILL_START — Skill invoked; target paths and context noted.
• [YYYY-MM-DDTHH:MM:SSZ] CANDIDATES_IDENTIFIED — List of cacheable query/endpoint candidates with read frequency and latency.
• [YYYY-MM-DDTHH:MM:SSZ] PATTERN_SELECTED — Chosen caching pattern per candidate with rationale.
• [YYYY-MM-DDTHH:MM:SSZ] IMPLEMENTATION_COMPLETE — Files modified, key schema applied, TTLs configured.
• [YYYY-MM-DDTHH:MM:SSZ] INVALIDATION_CONFIGURED — Invalidation strategy and triggers documented.
• [YYYY-MM-DDTHH:MM:SSZ] METRICS_ADDED — Cache-hit/miss instrumentation added; metric names listed.
• [YYYY-MM-DDTHH:MM:SSZ] TESTS_PASSED — Existing test suite executed post-change; pass/fail status.
• [YYYY-MM-DDTHH:MM:SSZ] CACHE_SKILL_END — Skill completed; summary of cache-hit ratio improvement (if measurable).