cachinglisted

# Caching ## Purpose Add a cache with a clear invalidation story, or find out why the existing one is serving stale data. A cache is a second source of truth; introducing one is a consistency decision, not just a performance one. ## When to Use - A read path is slow and the data is read far more often than it is written. - An upstream dependency is expensive, rate-limited, or unreliable. - Debugging stale reads, cache stampedes, or unexplained memory growth. ## Capabilities - Cache placement: client, CDN, application, database. - Strategies: cache-aside, read-through, write-through, write-behind. - Invalidation: TTL, explicit, event-driven, versioned keys. - Stampede protection: locking, early recomputation, request coalescing. - Negative caching and hot-key mitigation. ## Inputs - The read/write ratio and the cost of the uncached path. - How stale the data is allowed to be — in seconds, agreed with the product owner. - Cardinality of the key space and expected memory footprint. ## Outputs - A key schema, a TTL, and an invalidation trigger for each cached entity. - Stampede protection on any key expensive enough to matter. - A hit-rate metric, because a cache you do not measure is a cache you do not understand. ## Workflow 1. **Prove the need** — Measure the uncached path first. A cache in front of a missing index is a permanent workaround for a five-minute fix. 2. **Decide the staleness budget** — Ask what breaks if a user sees data five seconds old. The answer d