Recently I interviewed a Senior Backend Engineer. Strong candidate. Load balancing? ✅ Caching? ✅ Database indexing? ✅ Horizontal scaling? ✅ Then I asked: "You're building a product listing service. A product becomes viral. Suddenly, 50,000 requests per second hit the same product ID." Your database is struggling. You add Redis. Traffic drops at the database, and everything looks good. Then the product price changes. For the next 30 seconds, some users see the old price while others see the new one. Worse, an old request finishes late and overwrites the updated cache entry. How do you prevent stale data from coming back?" "Just invalidate the cache." What if an in-flight request repopulates it with stale data immediately after invalidation? "Use a short TTL." What if the business requires price changes to be reflected immediately? "Use a distributed lock." What happens when thousands of requests wait on that lock? Now you've traded stale reads for a latency problem. Your turn: How would you design the cache update and invalidation flow to handle concurrent reads, writes, and delayed requests without serving stale prices? There's a subtle distributed-systems problem hiding behind cache invalidation. And it gets much harder when your cache is distributed across multiple application instances.