Scaling Reads hard
You want to prevent cache stampedes without using locking. You implement 'Probabilistic Early Expiration' (X-Fetch). How does this algorithm work?
- A It returns a 404 error randomly.
- B It creates a background thread to update all keys every second.
- C It uses a variable TTL. When a client reads a key, if the TTL is close to expiring (within a 'Gap' window), the client voluntarily recomputes the value based on a probability function.
- D It relies on the database to push updates.
Answer: C. It uses a variable TTL. When a client reads a key, if the TTL is close to expiring (within a 'Gap' window), the client voluntarily recomputes the value based on a probability function.
This approach is non-blocking. As the expiration time approaches, the chance of *one* request triggering a refresh increases. This effectively refreshes the data *before* it actually expires, preventing the stampede entirely.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In a caching system, what is a 'Cache Miss'?
- Why is `SELECT * FROM Users` generally discouraged in high-performance applications compared to `SELECT name, email FROM Users`?
- You have users all over the world downloading large images from your server in New York. Users in Australia complain it is slow. What solves this?
- What is the main downside of reading from a Read Replica instead of the Primary database?
- You have maximized the RAM on your single database server, but it's still too slow. You decide to add 10 more servers to share the load. What is this called?
- You have 5 Read Replicas. How does the application know which one to ask for data?