You are in a Staff Engineer system design interview. The interviewer draws a simple architecture on the whiteboard: an API, a Redis cache, and a Postgres database.
Then they drop the scenario:
"A highly popular key reaches its TTL (Time-To-Live) and expires. In the exact same second, 40,000 requests arrive looking for that key. What happens, and what do you change to prevent the database from melting?"
Most engineers immediately start talking about scaling the database or adding read replicas. But if you say that, you've missed the hidden signal the interviewer is actually scoring you on.
Here is exactly how a Staff Engineer tackles the Cache Stampede (also known as a Thundering Herd) problem.
