Challenge 3: Diagnose a Stampede — Possible Solution
====================================================================

DIAGNOSIS: this is a textbook cache stampede (thundering herd /
dog-piling). The product page's cache key almost certainly expired
(its TTL ran out), and since it's a POPULAR page, a large number of
concurrent requests were already in flight or arrived within the same
narrow window right after expiration. Every one of those requests
independently checked the cache, found it empty (a miss), and — with
no coordination between them — each one proceeded to query the
database on its own, producing the sudden 200-query spike for what
should have been a single database read followed by 199 cache hits.

THE FIX: introduce the lock-based protection this chapter described.
Before querying the database on a cache miss, a request attempts
SET lock:product:<id> "1" NX EX 5. Only the FIRST request to arrive
after expiration successfully acquires this lock and proceeds to query
the database and repopulate the cache; every other concurrent request
that fails to acquire the lock backs off briefly (e.g. sleep 50ms) and
retries reading the now-likely-repopulated cache instead of querying
the database itself.

This turns "200 requests, 200 database queries" into "200 requests, 1
database query" — the same page being requested at the same volume,
but with only the genuinely necessary single database read actually
happening. Adding jitter to the TTL (this chapter's tip box) would
also help prevent this SPECIFIC key from repeatedly hitting the exact
same expiration moment on future cycles, though the lock is the direct
fix for the concurrent-miss problem itself.