Caching hard
Why is deleting a 5GB List in Redis dangerous?
- A It leads to a massive, non-recoverable memory fragmentation event that prevents the server from allocating contiguous space for new objects.
- B It blocks the single execution thread during memory reclamation, causing a multi-second freeze for all other clients connected to the server.
- C It will fail with a fatal Out Of Memory (OOM) error because the engine lacks the ability to swap large data structures out to a temporary disk-based store.
- D It risks corrupting the primary Append Only File (AOF) if the deletion event is not successfully committed before a background synchronization event occurs.
Answer: B. It blocks the single execution thread during memory reclamation, causing a multi-second freeze for all other clients connected to the server.
In single-threaded systems like Redis, deleting a large object (e.g., a List with 10 million items) is an interactional O(N) operation. The thread must deallocate every item individually. While this happens, the event loop is blocked, causing high latency or timeouts for all other clients. Redis 4.0's `UNLINK` command solves this by moving reclamation to a background thread.
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?