Traditional caches give you the same tradeoff: pick one refresh interval, and it applies to everything. Stable data gets refreshed more than it needs to while volatile data sits stale longer than you'd like. Tune one, you compromise the other.
That's why we built Adaptive Cache, which is available today as part of the Readyset Platform. Adaptive Cache adjusts the refresh interval per cached result based on how frequently that result actually changes, with no manual tuning required.
In our testing, p95 staleness dropped 97% compared to a standard TTL cache, with only a 60% increase in upstream refresh load instead of the 490% increase you would need to achieve the same result by manually shrinking the interval.
This is a key step toward caching that's truly invisible, no tuning, no babysitting.
Top comments (1)
Interesting result. The part I’d want in the benchmark contract is what “p95 staleness” is sampled over. Read-weighted p95 can look excellent while cold keys, low-traffic tenants, deletes, or authorization changes remain stale for a long tail. I’d report both request-weighted and key/tenant-weighted distributions, plus a hard maximum freshness bound per data class. The adversarial cases matter too: a previously stable key that changes suddenly, bursty updates followed by silence, delete/revoke events, clock skew, refresh failures, and an upstream change while the prior refresh is still in flight. A version or source-watermark on each cached result would make the guarantee inspectable (
observed_at,source_version,refresh_due_at, stale reason) and prevent an older refresh from overwriting a newer one. Finally, adaptive policy must stay inside the authorization-aware cache key; learning volatility across principals or tenants must not accidentally make results shareable. The load/staleness tradeoff is compelling—the tail and correctness definitions will determine whether teams can safely build an SLO around it.