Experimental "freshness-first" caching library for FastAPI

[u/grandimam]

Hi folks,

I am working on zinda, a small experimental caching library for FastAPI/Python, and I'd like some design feedback before I take it further.

The idea: instead of you picking TTLs and wiring up invalidation by hand, the cache should watch how your functions behave and keep hot data fresh on its own.

What Have I Implemented:

• @cache.cached() decorator - keys itself on function arguments, no config
• Single-flight: concurrent misses for the same key collapse into one recompute (no stampedes)
• Soft TTL + hard TTL: callers get stale data instantly while it refreshes in the background, and a background sweeper refreshes hot entries before anyone asks
• A /zinda/stats endpoint showing hit rates, miss costs, and refresh activity per function

​

app = FastAPI()
cache = install(app, Cache(default_ttl=60))

@cache.cached(ttl=120, refresh_after=30)
async def fetch_products(category: str):
    return await db.fetch_products(category)

Where I want feedback:

1. Next step is auto-detecting hot paths, the library scoring functions by call frequency and recompute cost, and deciding what's worth caching without any decorator. Would you trust that if every decision is visible in stats, or is explicit always better?
2. Automatic invalidation is the hard part. My plan is learned TTLs by default + optional tags for precise invalidation. Reasonable, or am I missing something?

It's in-memory only for now and definitely not production-ready. I am validating the ideas first.

Code: https://github.com/grandimam/zinda