Caching medium
What widespread race condition does the 'Delayed Double Delete' pattern address?
- A Conflicts arising from two independent writers attempting to update the same database record simultaneously during a peak traffic window.
- B A reader fetching stale data and writing it to the cache after a concurrent writer has already performed a primary cache invalidation.
- C Scenarios where the cache cluster process crashes during a write operation, leaving the database and cache in a permanently divergent state.
- D Inconsistencies caused by the inherent replication lag between the primary database instance and its globally distributed read-only replicas.
Answer: B. A reader fetching stale data and writing it to the cache after a concurrent writer has already performed a primary cache invalidation.
The **Delayed Double Delete** strategy handles a specific race condition in Cache-Aside: A reader reads stale data from the DB just as a writer updates the DB and invalidates the cache. The reader then writes the stale data *back* to the cache. By deleting the cache key *again* after a short delay (e.g., 500ms), the writer ensures this stale value is flushed.
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?