Hot Cache & Read Path Stability

Our Node/TypeScript product catalog uses Redis in front of PostgreSQL. A top-selling product key has a 5-minute TTL. When it expires, 200–500 concurrent requests all miss Redis and call the same expensive SQL query. We already have a Redis lock, but its lease is 2 seconds while the query sometimes takes 4–6 seconds, so another request can acquire the lock before the first fill completes. Waiting requests poll every 50 ms, and on refresh failure every caller bypasses cache. Repair the repository so one hot-key expiry does not create a thundering herd. Use local Redis/test fixtures and deterministic concurrency tests. Do not flush production Redis, change live infrastructure, or invent a new freshness SLA.

Cache stampede found. A hot-key expiry triggers parallel SQL fills because the lock lease is shorter than the fill, followers poll aggressively, and refresh failure bypasses the cache per caller. The repair adds per-key coalescing, safer distributed ownership, generation protection, bounded follower behavior, concurrency tests, and fill metrics. Production capacity and freshness policy remain unverified.