Caching hard
Why is 'Delete-on-Write' (Invalidate) preferred over 'Update-on-Write' (Set) for maintaining cache consistency?
- A The overhead of performing a cache deletion is significantly lower than executing a full update command on the primary server thread.
- B The update operation is inherently idempotent across multiple regional nodes, ensuring that subsequent writes do not conflict with each other.
- C Deletes are safer against race conditions where convergent writes arriving out of order can leave stale data permanently stored in the cache.
- D Performing partial updates to a cached object consumes significantly more network bandwidth than simply invalidating the entire resource key.
Answer: C. Deletes are safer against race conditions where convergent writes arriving out of order can leave stale data permanently stored in the cache.
In a distributed system, concurrent writes often arrive out-of-order. If Writer A (Val=1) and Writer B (Val=2) update the cache, but the network delivers B's update before A's, the cache effectively reverts to Val=1 (stale). **Deleting** (Invalidating) the key avoids this: the next reader will simply fetch the officially committed value from the DB.
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?