Database / REDIS
Explain the lifecycle of a key with a TTL set in Redis?
A key's TTL doesn't trigger a background timer that fires exactly at expiration — Redis uses a combination of lazy and active strategies to actually reclaim expired keys, which is worth understanding since it explains some otherwise-surprising behavior around memory and replication.
flowchart TD
A[Key created with EXPIRE/EX/PX] --> B[Expiration timestamp stored alongside the key]
B --> C{Key accessed by a client command before expiring?}
C -- Yes, and TTL has passed --> D[Lazy expiration: key deleted on access, treated as if it doesn't exist]
C -- No access yet --> E[Key remains in memory, technically expired but not yet removed]
E --> F[Active expiration cycle runs periodically in the background]
F --> G[Redis samples a set of keys with TTLs, deletes any that have expired]
G --> H{Sampled expired-key ratio still high?}
H -- Yes --> F
H -- No --> I[Cycle pauses until next scheduled run]
D --> J[Expiration event propagated to replicas as an explicit DEL command]
I --> J
The propagation detail in step J matters for consistency: replicas don't independently decide a key has expired based on their own clock — the master is the source of truth for expiration, and sends an explicit DEL/UNLINK to replicas once it expires a key, which avoids replicas disagreeing about whether a key is still valid due to clock drift or replication lag.
What are the two mechanisms Redis uses to actually reclaim expired keys?
How does a replica learn that a key has expired?
More Related questions...
