Caching medium
You cache 50,000 product prices with a strict TTL of 1 hour. At 12:00 PM, you restart the app, populating the cache. At 1:00 PM, the database spikes to 100% CPU. Why, and how do you fix it?
- A This is a 'Thundering Herd' event caused by parallel computation; fix it by implementing Request Coalescing at the application layer.
- B This is a 'Cache Avalanche' caused by synchronized expirations; fix it by adding a random time jitter to the TTL during cache population.
- C This is a 'Hot Key' contention issue on the distribution ring; fix it by migrating the frequently accessed shards to localized L1 memory.
- D This is a 'Network Partition' causing the cache cluster to diverge; fix it by deploying a Circuit Breaker to fail-fast during the rollout.
Answer: B. This is a 'Cache Avalanche' caused by synchronized expirations; fix it by adding a random time jitter to the TTL during cache population.
**Cache Avalanche** occurs when a large number of cached items expire at the same time, causing a synchronized spike in database load as the application tries to refresh them all. Adding **Jitter** (randomness) to the TTL ensures that expirations are spread out over time, smoothing the load on the database.
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?