Skip to content
intermediatePhase 46 · Caching

TTL (Time To Live)

Set expiration times on cached entries for automatic freshness.

30m
0 problems
Topic Progress0%

Setting TTL

Setting TTL Values

TTL (Time To Live) defines how long cached data remains valid before automatic expiration.

TTL Setting Guidelines

# Data type TTL recommendations
TTL_CONFIG = {
    # User data
    'user:profile': 3600,      # 1 hour
    'user:session': 1800,      # 30 minutes
    'user:preferences': 86400, # 24 hours
    
    # Product data
    'product:details': 7200,   # 2 hours
    'product:inventory': 60,   # 1 minute (frequently changing)
    'product:price': 300,      # 5 minutes
    
    # Static content
    'config:app': 86400,       # 24 hours
    'config:features': 3600,   # 1 hour
    
    # Aggregations
    'stats:daily': 3600,       # 1 hour
    'stats:weekly': 86400,     # 24 hours
}

Factors for TTL Selection

Factor Short TTL Long TTL
Data volatility High change rate Low change rate
Freshness requirement Real-time needed Can be stale
Cost of staleness High impact Low impact
Cache capacity Limited Abundant
Access frequency Rarely accessed Frequently accessed

Redis TTL Commands

# Set with TTL
SET user:123 "data" EX 3600

# Check TTL
TTL user:123  # Returns seconds remaining

# Update TTL
EXPIRE user:123 7200

# Remove TTL
PERSIST user:123

# Set if not exists with TTL
SETNX user:123 "data" EX 3600

TTL Strategies

TTL Strategies

Fixed TTL

def set_fixed_ttl(key, value, ttl=3600):
    """Same TTL for all entries"""
    cache.setex(key, ttl, value)

Sliding TTL (Refresh on Access)

def get_with_sliding_ttl(key, ttl=3600):
    """Refresh TTL on each access"""
    value = cache.get(key)
    if value is not None:
        cache.expire(key, ttl)  # Refresh TTL
    return value

# Alternative: Use pattern
value = cache.getset(key, value)  # Get and set atomically
if value:
    cache.expire(key, ttl)

Adaptive TTL

def calculate_adaptive_ttl(access_count, base_ttl=3600):
    """Adjust TTL based on access frequency"""
    if access_count > 1000:  # Very popular
        return base_ttl * 2   # Extend TTL
    elif access_count > 100:  # Popular
        return base_ttl        # Normal TTL
    else:                      # Not popular
        return base_ttl // 2   # Shorter TTL

Stale-While-Revalidate

def get_swr(key, loader, ttl=300, stale_ttl=3600):
    """Serve stale while refreshing in background"""
    data = cache.get(key)
    
    if data:
        data = json.loads(data)
        age = time.time() - data['timestamp']
        
        if age < ttl:
            return data['value']  # Fresh
        elif age < stale_ttl:
            # Stale but usable, refresh async
            background_refresh(key, loader, stale_ttl)
            return data['value']  # Stale
    
    # No data or too stale, must load sync
    value = loader()
    cache.setex(key, stale_ttl, json.dumps({
        'value': value,
        'timestamp': time.time()
    }))
    return value

TTL Monitoring

TTL Monitoring

Key Metrics

# Monitor TTL distribution
async def monitor_ttl_distribution():
    """Track TTL health across cache"""
    stats = {
        'expired_soon': 0,  # TTL < 60s
        'healthy': 0,       # TTL > 300s
        'long_lived': 0     # TTL > 3600s
    }
    
    for key in cache.scan_iter():
        ttl = cache.ttl(key)
        if ttl < 0:
            continue  # No TTL set
        elif ttl < 60:
            stats['expired_soon'] += 1
        elif ttl < 3600:
            stats['healthy'] += 1
        else:
            stats['long_lived'] += 1
    
    return stats

Monitoring Dashboard Metrics

Metric Description Alert Threshold
TTL Distribution Spread of TTL values Imbalance
Expiration Rate Keys expiring per minute Sudden spike
Cache Miss Rate Misses due to expiration > 20%
Avg TTL Average TTL across keys Too short/long

Redis TTL Monitoring

# Get keys with short TTL
SCAN 0 MATCH "*" COUNT 100
# Then check TTL for each

# Monitor expiration events
CONFIG SET notify-keyspace-events Ex
SUBSCRIBE __keyevent@0__:expired

Best Practices

  1. Set TTL for all keys - prevents memory leaks
  2. Monitor expiration rates - detect issues early
  3. Use consistent TTL patterns - easier to reason about
  4. Document TTL decisions - for team understanding
  5. Review TTLs regularly - adjust based on usage

Practice Problems

0/3solved
Design TTL (Time To Live) System

Design a scalable TTL (Time To Live) system. Cover high-level architecture, data model, and API design.

Solution
// Complete system design:
// - Functional + Non-functional requirements
// - Capacity estimation
// - Data model (SQL/NoSQL choice)
// - API endpoints
// - Component architecture
// - Scaling strategy
// - Monitoring & reliability
TTL (Time To Live) Scaling

How would you scale TTL (Time To Live) to handle 10x the current load? Identify bottlenecks and solutions.

Solution
// Scaling approach:
// 1. Load balancing
// 2. Database sharding/replication
// 3. Cache layer (Redis)
// 4. CDN for static assets
// 5. Async processing (queues)
// 6. Microservices decomposition
TTL (Time To Live) Failure Modes

Analyze potential failure modes for TTL (Time To Live) and design mitigation strategies.

Solution
// Failure mitigation:
// 1. Redundancy (multi-AZ)
// 2. Circuit breakers
// 3. Retry with backoff
// 4. Dead letter queues
// 5. Health checks
// 6. Graceful degradation

Quiz

1. What does TTL stand for in caching?

Question 1 options

2. What happens when a cached item's TTL expires?

Question 2 options

3. When should you use a short TTL (e.g., 1 minute)?

Question 3 options

4. What is sliding TTL?

Question 4 options

5. Why is it important to set TTL for all cache entries?

Question 5 options

Flashcards

Question

What is TTL in caching?

Answer

Time To Live - the duration a cached entry remains valid before automatic expiration and deletion

Question

What is sliding TTL?

Answer

TTL that refreshes on each access, keeping active data cached longer while allowing inactive data to expire

Question

Why set TTL on all cache entries?

Answer

To prevent memory leaks - ensures old data is cleaned up even if explicit invalidation fails

Question

When use short TTL vs long TTL?

Answer

Short: frequently changing data, real-time needs. Long: static data, high access frequency, low staleness cost.

Question

What is TTL (Time To Live)?

Answer

TTL (Time To Live) is a key concept in system design.

Revision Notes

Key Takeaways

  • 1.TTL is the automatic expiration time for cached data
  • 2.Always set TTL to prevent memory leaks
  • 3.Sliding TTL keeps active data cached longer
  • 4.Match TTL to data freshness requirements
  • 5.Monitor TTL distribution and expiration rates

Interview Tips

  • Explain TTL as a safety net for cache invalidation
  • Discuss trade-offs: short TTL = fresh but more misses, long TTL = less misses but stale
  • Mention sliding TTL for active data patterns
  • Emphasize monitoring TTL health in production

Cheat Sheet

Cheat Sheet: TTL

What is TTL

  • Time To Live: duration before auto-expiration
  • Safety net for cache invalidation

TTL Strategies

  • Fixed: Same for all entries
  • Sliding: Refresh on access
  • Adaptive: Based on access patterns
  • Stale-While-Revalidate: Serve stale, refresh async

Redis Commands

  • SET key value EX seconds
  • TTL key (check remaining)
  • EXPIRE key seconds (update)
  • PERSIST key (remove TTL)

Monitoring

  • Track TTL distribution
  • Monitor expiration rates
  • Alert on anomalies