01A key expired five minutes ago but has not been accessed. Why might it still occupy memory?introScenarioA memory profile shows keys whose TTLs passed long ago still resident in the keyspace.AA background defragmenter owns expired-key deletion and only runs when memory becomes fragmented.BIt may still occupy memory because Redis expiration is partly lazy; cold keys can remain until active sampling finds them.CExpired keys are deliberately retained until the next RDB save so the snapshot stays consistent.DReads of other keys in the same hash bucket refresh neighboring deadlines, silently extending the key's TTL, a side effect of how the shared bucket metadata gets updated.
02What should `GET expired-key`, `EXISTS expired-key`, and startup recovery all agree on?introScenarioYou are checking that every read path in the server treats a dead-but-undeleted key the same way.AThey should agree on physical deletion, with all three observing that the memory has already been freed.BGET and EXISTS should agree the key is gone, but recovery may resurrect it briefly until the first access.CThey only need to agree on the TTL value itself; whether the key is visible may differ per code path.DThey should agree that the key is logically gone once its absolute deadline has passed.
03Why do absolute expiration timestamps make persistence and recovery safer than relative TTLs?appliedScenarioYou are choosing how TTL state should be recorded so it survives saves, restarts, and replication.AAbsolute timestamps are smaller to store than relative TTLs, which keeps persistence files compact.BRelative TTLs are unsafe because clients cannot compute them; only the server clock can be trusted.CAbsolute timestamps survive downtime correctly, while relative TTLs can accidentally restart the countdown after persistence or recovery.DAbsolute timestamps let replicas expire keys on their own schedule, improving availability when the primary becomes unreachable during a failover.
04Compare passive expiration and active expiration by cost, precision, and coverage.appliedScenarioYou are weighing the two expiration mechanisms that share responsibility for removing dead keys.APassive expiration is cheap and precise for accessed keys but misses cold keys; active expiration costs background work and is approximate but covers cold keys.BActive expiration is precise and free because it runs in idle time, while passive expiration adds latency to every read.CPassive expiration eventually covers all keys because every key is read eventually; the active cycle exists only for metrics.DThey differ only in their trigger; both scan the whole expires dictionary, so cost and coverage are identical.
05Why should expiration checks live in shared lookup logic instead of each command handler?advancedScenarioA code review found a proposal to add TTL checks separately inside each command's handler.AHandlers should each check expiration themselves, so they can customize TTL behavior per command — GETEX-style commands prove per-command TTL behavior is sometimes wanted.BExpiration belongs only in the active cycle, and lookups should trust the keyspace to already be clean.CExpiration belongs in the RESP layer, which can filter out replies that mention expired keys.DShared lookup logic keeps every read and existence check consistent, instead of relying on each command handler to remember expiration rules.
fivenines