Dealing With Contention hard
A popular cache key expires. 10,000 requests try to read it, find it missing, and ALL query the DB to recompute it. This crashes the DB. What is the standard pattern to prevent this?
- A Sharding the database.
- B Increasing the cache size.
- C Singleflight (Request Coalescing). The first request acquires a lock to recompute. The other 9,999 requests block and wait for the first request to finish, then share the result.
- D Disabling the cache.
Answer: C. Singleflight (Request Coalescing). The first request acquires a lock to recompute. The other 9,999 requests block and wait for the first request to finish, then share the result.
Also known as a 'Cache Stampede' defence. Solutions include Singleflight or Probabilistic Early Expiration (recomputing before it actually expires).
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- Why is 'Exponential Backoff' preferred over constant intervals for retries?
- What is the primary purpose of a Mutex (Mutual Exclusion) lock?
- Why does adding more threads sometimes *decrease* performance?
- In a Saga, if a Compensating Transaction (Undo) fails repeatedly due to contention, what is the last resort?
- In a database, what happens if Transaction A locks a row and Transaction B tries to modify the same row?
- A database restart causes thousands of application servers to instantly try to reconnect. This crashes the DB again. This is called: