cachinglisted

# Caching Put a copy of hot data closer to the reader so most requests skip the slow path. Caching is the highest-leverage move for read-heavy systems — and the easiest to get subtly wrong, because a cache adds a second source of truth that can serve stale or wrong data, and can *amplify* an outage when it misbehaves. ## When to reach for this Reads dominate (a high read:write ratio from `back-of-the-envelope`); the same data is read repeatedly; the datastore is the read bottleneck; or recomputation is expensive. A cache buys read latency and offloads the origin. ## When NOT to Write-heavy or read-once data (low hit rate — pure overhead). Data that must be exactly current with zero staleness (a cache is a stale copy by nature; when strict freshness is required, go to the source or use `consistency-coordination`). Don't add a cache before a number shows reads are the problem (YAGNI) — it's a new failure mode and a second thing to operate. ## Clarify first - **Read:write ratio and hit rate** — is the working set cacheable? (→ `back-of-the-envelope`, 80/20.) - **Staleness tolerance** — seconds? minutes? must reads see their own writes? - **Working-set size** — does the hot set fit in RAM across cache nodes? - **Consistency on write** — can the cache briefly disagree with the store? - **Eviction trigger** — what's the access pattern (recency? frequency? time-bound?). ## The options **Where to cache** (often layered): client/browser → CDN edge (→ `content-delivery`) → applic