uwsgi cache stampede mitigation without stale-while-revalidate support

uwsgi's built-in cache subsystem uses strict TTL expiration: when a hot key expires, every concurrent request blocks while the application regenerates the value. The documentation confirms there is no native stale-while-revalidate, probabilistic early expiration, or lease-based refresh mechanism in uwsgi 2.0.x. Local caches are per-worker, so each process independently triggers regeneration, while external backends (redis, memcached) share state but still lack atomic get-or-refresh primitives.

This creates a thundering-herd problem on high-traffic keys. The cache2 API added namespaces and key iteration but did not introduce invalidation hooks or asynchronous refresh callbacks. TTL granularity is limited to whole seconds, and graceful reloads discard local cache contents entirely.

Given these constraints, what patterns have proven effective for preventing cache stampedes in production uwsgi deployments? Does the community rely on application-level locking, external cache layers with native stale-while-revalidate, or probabilistic early expiration? Which approach integrates cleanly with uwsgi's worker model and reload semantics?