Skip to content

TTL (Time-To-Live)

1. What is it? (2-3 lines)

Time-To-Live (TTL) is a mechanism that attaches a temporal expiration lifespan to a cached data key or network packet. Once the specified TTL duration elapses, the key automatically expires and is evicted or made inaccessible by the storage engine.

2. Why does it exist?

Cache memory (RAM) is finite and far more expensive than disk storage. Without TTL expiration, stale cached data accumulates indefinitely, eventually causing Out-Of-Memory (OOM) crashes or serving permanently outdated data to users when primary database records change.

3. Where is it used?

  • In-Memory Data Stores: Redis (EXPIRE key 3600, PEXPIRE), Memcached.
  • Networking & DNS: DNS Record TTLs (A/AAAA record caching), IP packet TTL (hop limit in IPv4/IPv6).
  • Web & CDNs: HTTP headers (Cache-Control: max-age=3600), Browser local caching.

4. How does it work? (simple flow)

  • Expiration Mechanism in Redis:
  • Passive Expiration (On Read): When a client executes GET key, Redis checks its expiration timestamp. If currentTime > expireTime, key is deleted immediately and returns null.
  • Active Expiration (Background Sampling): Every 100ms, Redis tests 20 random keys with active TTLs \(\to\) Deletes all expired keys \(\to\) If \(>25\%\) of sampled keys were expired, repeats immediately.
  • Volatile Eviction: If RAM limit is reached before TTL expires, Redis applies eviction policies (volatile-lru, volatile-ttl).

5. Advantages

  • Enforces automatic bound on data staleness without manual invalidation code.
  • Prevents memory leaks by automatically reclaiming RAM from unused historical keys.
  • Protects downstream systems by ensuring eventual consistency after data mutations.

6. Limitations

  • Setting TTLs too short causes low cache hit ratios and high database read load.
  • Setting TTLs too long risks serving stale data to end users after database updates.
  • Uniform TTLs across millions of keys risk triggering a Cache Avalanche.

7. Common interview questions (10)

  1. How does Redis implement Passive vs Active TTL Key Expiration under the hood?
  2. Why should developers add Randomized Jitter to static TTL values?
  3. What is the difference between TTL Expiration and Memory Eviction (e.g. LRU) in Redis?
  4. How do DNS Record TTLs impact failover latency when switching IP addresses during an outage?
  5. What is the Soft TTL vs Hard TTL pattern and how does it prevent Cache Stampedes?
  6. What happens to a key's TTL when it is overwritten using a standard SET command in Redis without specifying KEEPTTL?
  7. How does the HTTP Cache-Control: max-age header dictate browser and CDN edge TTL behavior?
  8. How does TTL management differ between Redis (single-threaded active sampling) and Memcached (lazy expiration)?
  9. How do sliding TTLs (refreshing TTL on read) differ from fixed TTLs?
  10. What memory management risks occur if 90% of Redis keys have zero TTL (no expiration set)?

8. Common misconceptions

  • Misconception: Setting a 1-hour TTL guarantees data will stay in cache for 1 hour. Fact: Memory pressure can trigger LRU/LFU eviction to delete the key long before its TTL expires!
  • Misconception: Expired keys are deleted from memory the exact millisecond TTL hits zero. Fact: Keys are deleted passively on access or lazily during background sampling sweeps.

10. 30-second cheat sheet

  • Definition: Expiration lifespan attached to a key (EXPIRE key 3600).
  • Redis Internal: Passive (delete on GET) + Active (sample 20 keys every 100ms).
  • TTL vs Eviction: TTL = Time-based deletion; Eviction = Memory-full forced removal.
  • Rule of Thumb: Always add Random Jitter (TTL = Base + rand()) to avoid Cache Avalanches!