What happens when a popular cache entry expires for many requests at once?
Answer out loud or in your head first, then compare.
Answer
Many requests may ask the main database for the same thing at the same time. That can suddenly overload it. You can limit this by refreshing one shared result, or by carefully serving an older version if the data allows it. Spreading out expiry times also helps.
It's important to know what the app does when the cache fails. For a supporting list you can read the database with limited traffic. For a security rule you mustn't automatically treat everyone as authorised. Local protection on one server doesn't coordinate other servers. First I establish where the real data comes from and how much delay is acceptable.
Why it matters: Teaches thinking about an optimisation failing, not just about faster reads.
Possible follow-ups: Can older permission data be treated like an older product description?
How did it go? Be honest — “Not yet” puts the question on your review list.
Start with
- D-P01 · What is HTTP, and what do a request and a response look like? — Backend, data and system design
- D-P10 · What is a database transaction? — Backend, data and system design
- D-P13 · What is a message queue, and why do we use one? — Backend, data and system design
Further reading
- Cloudflare: How KV works(opens in a new tab)Docs; accessed 22.10.2026. Eventual consistency, including caching of missing keys; no atomic KV transactions.