Caching medium
Redis processes commands on a single thread. What is the operational danger of running a command like `KEYS *` (or deleting a huge 2GB Set)?
- A It consumes an excessive amount of system RAM, potentially triggering an OOM (Out of Memory) crash of the primary Redis process.
- B It blocks the entire single-threaded event loop, preventing all other clients from performing any read or write operations during execution.
- C It creates a dangerous race condition with parallel background writes that can lead to partial data corruption within the keyspace.
- D It forces the Redis server to immediately flush all in-memory data to the disk-based persistent store, causing a massive I/O bottleneck.
Answer: B. It blocks the entire single-threaded event loop, preventing all other clients from performing any read or write operations during execution.
Redis is **single-threaded**. It executes commands sequentially. A command with O(N) complexity, like `KEYS *` or deleting a massive key, monopolizes the CPU. During this time, ALL other clients are blocked, leading to timeouts and potential system-wide unavailability. Use `SCAN` instead of `KEYS` and `UNLINK` for async deletion.
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?