Scenario: a cache stampede at peak hour Intermediate

One hot key, one livestream sale evening, four decisions. You will stop the bleeding on an overloaded database, fix the root cause, then hit two cache-aside bugs that leave no log line at all.

• Before choosing, estimate quickly: request rate × reload time is the number of requests that miss together.
• If you pick wrong, read the explanation and Try again. Scoring counts only your first choice at each step.

Scenario

Livestream sale: the home page takes down the database every 5 minutes

You are the backend dev owning the home page: 20 instances, each with a pool of 10 PostgreSQL connections, Redis cache in cache-aside style. Each choice immediately shows its consequences on the metrics below.

PostgreSQL CPU97 %

Home page p994,200 ms

Concurrent home page queries200

Old price still shown0 min

Step 1/4 · The DB is overloaded, right now

20:00, livestream sale, the home page receives 4,000 requests/s. The key home:products has a fixed 300-second TTL; the query that loads it takes 0.8 seconds normally. Every 5 minutes database CPU spikes, and this time it does not come down.

PostgreSQL connections

200/200 (20 × pool 10)

pg_stat_activity

200 rows of the same TOP_PRODUCTS_SQL

expired_keys

spikes exactly every 5 minutes

async function getHomeProducts() {
  const hit = await redis.get('home:products');
  if (hit) return JSON.parse(hit);
  const rows = await db.query(TOP_PRODUCTS_SQL); // 0.8 s, now 3 s
  await redis.set('home:products', JSON.stringify(rows), 'EX', 300);
  return rows;
}

What do you do?

AScale the app from 20 to 40 instances because p99 is highBSet statement_timeout = 1s on the home page query to free the DBCFlip a flag: each instance allows only 1 home page query at a time, other requests get a fallback snapshot; once the query finishes the cache refills itselfDHotfix the TTL from 5 minutes to 1 hour

After playing, read Cache stampede to compare a token-based lock, singleflight, XFetch and stale-while-revalidate.