Every caching conversation starts the same way: do you need a cache, and how do you implement it correctly? This talk skips that question. It starts after the cache is already live and already trusted — and shows what happens when nobody ever asks how it knows it's still right.

In most systems, TTL isn't a calculated decision but it is an assumption that got copy-pasted into a config field and never revisited. A single TTL is applied across attributes that change at completely different rates, which means it's never actually correct: too long for volatile fields, too short for stable ones. When the source of truth lives in an external system you don't control, the problem compounds, some systems expose a validity flag to tell you when data has changed, most don't, and none of them agree on the contract. The result is a cache that fails silently: it doesn't crash, it doesn't alert, it just quietly serves stale data dressed up as correct until a user notices and files a bug.

This session walks through a real caching setup built on exactly these assumptions, the failure it produces, and what it actually takes to make staleness visible instead of assumed including where "just check if it's still valid" breaks down when validation costs nearly as much as the fetch it was meant to avoid.