caching-strategieslisted

# Caching Strategies Caching is the cheapest order-of-magnitude performance win available, and the fastest way to serve *confidently wrong* data. The hard part was never reading from a cache — it's **invalidation**, **consistency under concurrency**, and **what happens the moment the cache is cold or wrong**. This skill is the deep reference: the patterns, the decisions, the trade-offs, and the failure modes that page you at 3am. Heavy detail lives in `references/`; copy-paste material in `examples/`; a runnable check in `scripts/`. ## Mental model A cache is a **bet**: you trade memory and a correctness risk for latency and load reduction. Every caching decision is answering four questions, in order: | Question | What it decides | |---|---| | What is hot and tolerant of staleness? | *whether* to cache at all | | How does data get *into* the cache? | the **read/write pattern** (cache-aside, write-through…) | | How does stale data get *out*? | **TTL + invalidation** | | What happens on a miss storm or a dead cache? | **stampede control + fallback** | If you can't answer the third and fourth questions before you ship, you don't have a caching strategy — you have a future incident. Decide the invalidation plan *first*. ## 1. What to cache Cache data that is **read-often, expensive to produce, and tolerant of some staleness**. Good candidates: rendered product pages, the result of an expensive aggregation, a third-party API response, a permission lookup hit on every reques