Redis hard
Why might 'Key Expired' events (`Ex` notification) be delivered significantly later than the actual moment the TTL reaches zero?
- A The internal notification bus uses a randomized retry delay to prevent saturating the client's network buffer.
- B Events are generated only when the key is physically deleted, which happens via lazy access or periodic random sampling.
- C Notifications are batched and flushed once per minute to minimize the overhead on the single-threaded event loop.
- D The expiration subsystem requires a dedicated client-side heartbeat to acknowledge the precise epoch of the key's death.
Answer: B. Events are generated only when the key is physically deleted, which happens via lazy access or periodic random sampling.
Redis does not 'stop the world' to delete keys exactly on time. It deletes them when someone tries to read them (Lazy) or when a background task samples them (Active). The event fires during this deletion, which can be seconds or minutes 'late'.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- If the Redis memory limit is reached, what specific behavior is exhibited by the `allkeys-lru` eviction policy?
- What is the defining characteristic of a Redis 'Set' data type compared to a standard Redis 'List'?
- In the context of Redis messaging, what is the functional definition of the 'Pub/Sub' feature?
- How does the Redis background snapshotting process (`BGSAVE`) leverage the operating system's `fork()` mechanism to minimize memory overhead?
- Why does Redis proactively disconnect a Pub/Sub client that exhibits high 'output buffer' usage relative to its ingestion rate?
- How does a 'Sorted Set' (ZSET) manage its internal membership and ordering differently from a plain Set?