Caching hard
To solve the Thundering Herd problem without locking, you implement 'Probabilistic Early Expiration' (X-Fetch). How does it works?
- A The cache server utilizes an internal entropy source to randomly delete and refresh keys before their scheduled expiration timestamp.
- B Clients perform a probabilistic check; as a key nears expiry, there is an increasing likelihood a client will recompute it in the background.
- C Distributed nodes participate in a light-weight consensus vote to elect a single 'refresh master' whenever a high-traffic key is invalidated.
- D The primary database management system triggers an asynchronous push notification to all subscribed cache nodes whenever a record is updated.
Answer: B. Clients perform a probabilistic check; as a key nears expiry, there is an increasing likelihood a client will recompute it in the background.
**Probabilistic Early Expiration** (or X-Fetch) prevents stampedes without locking. When a client fetches a cached value, it checks if the value is *close* to expiring (using a random delta to prevent synchronization). If it is, the client (or a background thread) eagerly re-fetches the data *before* it actually disappears, ensuring the cache always has a valid value and avoiding the 'miss storm'.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In the Cache-Aside pattern, what happens when the application requests data that is missing from the cache (a 'Cache Miss')?
- Why use a centralized Distributed Cache (like a Redis Cluster) over local in-memory caches on each web server?
- Setting a short TTL (e.g., 60 seconds) on a cached object helps to:
- What is the primary architectural goal of introducing a cache into a system?
- Most caching systems rely on the principle of 'Temporal Locality', which states:
- Your cache uses an LRU (Least Recently Used) eviction policy. When the cache is full, which item is removed?