Summary
Add entry-level cache policy support, starting with per-entry TTL and potentially expanding to stale-while-revalidate.
Why
The cache currently has one global TTL. Many real workloads need different lifetimes for different data types, and stale refresh can improve latency while keeping data reasonably fresh.
Current references
src/cache.ts: CacheEntry.timestampsrc/cache.ts: global ttl option and prune()
Review questions
- Should the entry model store
expiresAt instead of timestamp plus global TTL?
- Should per-entry TTL be accepted by
set() and getOrSet()?
- Is stale-while-revalidate part of this issue or a follow-up after per-entry TTL lands?
Acceptance criteria
set(key, value, { ttl }) or equivalent supports per-entry TTL.getOrSet() can cache fetched values with per-call TTL.- Global TTL remains the default when no entry TTL is provided.
- Pruning handles mixed TTL entries correctly.
Summary
Add entry-level cache policy support, starting with per-entry TTL and potentially expanding to stale-while-revalidate.
Why
The cache currently has one global TTL. Many real workloads need different lifetimes for different data types, and stale refresh can improve latency while keeping data reasonably fresh.
Current references
src/cache.ts:CacheEntry.timestampsrc/cache.ts: globalttloption andprune()Review questions
expiresAtinstead of timestamp plus global TTL?set()andgetOrSet()?Acceptance criteria
set(key, value, { ttl })or equivalent supports per-entry TTL.getOrSet()can cache fetched values with per-call TTL.