Cache stampede prevention: probabilistic vs mutex-based approaches

Cache stampedes are something we've encountered more than once. The classic scenario: a highly accessed cache key expires, and a flood of concurrent requests all try to recompute and populate it, often overloading the backend database or service. We've tried both mutex-based approaches (where only one request recomputes, others wait) and probabilistic early expiration (where a small percentage of requests refresh proactively). The mutex approach adds latency for waiting requests, which isn't ideal for our real-time APIs. Probabilistic doesn't always completely eliminate the problem, especially under heavy load, and can sometimes lead to slightly stale data if the refresh fails. We're now considering background cache warming for our most popular keys, where a dedicated worker keeps the cache fresh proactively. This adds complexity with separate jobs and monitoring. What's your preferred strategy for preventing cache stampedes in a high-traffic environment? Is there a combination of techniques that works best, or does it always depend on the specific access patterns?