caching-strategieslisted

Deciding whether to cache, then doing it safely: saved origin work and latency, bounded size or weight, TTL and jitter, stampede and its four distinct scopes, cache-aside versus refreshAfterWrite, immutable DTOs rather than JPA entities, invalidation across instances, Redis serialisation, and why hit rate alone is a misleading metric. Use when a cache is being added or reviewed, when @Cacheable is called from within the same bean, when a cache has no size limit or no TTL, when entries are preloaded in bulk with one TTL, when hit rate is the only metric on the dashboard, when Old Gen keeps growing, when FLUSHALL appears in a deploy pipeline, or when instances disagree about a value. Does not cover the pool the cache protects (connection-pool-sizing), the queueing arithmetic (littles-law-and-queueing), or GC tuning for the resulting heap (jvm-gc-tuning).
robsonkades/agent-skills · ★ 2 · Code & Development · score 75

Install: claude install-skill robsonkades/agent-skills

# Caching Strategies ## Purpose A cache can reduce the arrival rate seen by an origin in `L = λ × W`: a hit consumes no origin connection, planner or I/O. Batching, admission control and eliminating work can also reduce origin demand, so caching is one option rather than a unique law. A stale, unbounded cache can show excellent hit rate; correctness, memory and origin protection must be measured beside it. ## Workflow Inspect the target's Maven/Gradle release/toolchain, resolved Caffeine/Spring Data/Jackson versions, runtime image and cache configuration before choosing APIs. No universal Java baseline is declared here; the configuration reference states its example baseline. Preserve project versions and do not enable preview features or upgrade dependencies to fit an example. If workload, freshness requirements or measurements are absent, identify the gap and offer a conditional decision and measurement plan rather than inventing a hit rate or safe TTL. 1. **Measure source cost and capacity** (latency distribution, CPU/I/O and rate) before deciding. Even a sub-millisecond lookup may matter at very high volume; latency alone is not the case. 2. **Measure the access distribution** and estimate `h` for the intended `maximumSize`. 3. **Model saved work and latency, not hit rate alone.** Estimate origin work avoided by hit distribution and compare `h·T_hit + (1-h)·T_miss` (including queueing/load cost) with the uncached distribution. Tail latency cannot be derived