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
- Set TTL for all keys - prevents memory leaks
- Monitor expiration rates - detect issues early
- Use consistent TTL patterns - easier to reason about
- Document TTL decisions - for team understanding
- Review TTLs regularly - adjust based on usage
Practice Problems
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 & reliabilityHow 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 decompositionAnalyze 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 degradationQuiz
1. What does TTL stand for in caching?
2. What happens when a cached item's TTL expires?
3. When should you use a short TTL (e.g., 1 minute)?
4. What is sliding TTL?
5. Why is it important to set TTL for all cache entries?
Flashcards
Question
What is TTL in caching?
Click to reveal answer
Answer
Time To Live - the duration a cached entry remains valid before automatic expiration and deletion
Question
What is sliding TTL?
Click to reveal answer
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?
Click to reveal answer
Answer
To prevent memory leaks - ensures old data is cleaned up even if explicit invalidation fails
Question
When use short TTL vs long TTL?
Click to reveal answer
Answer
Short: frequently changing data, real-time needs. Long: static data, high access frequency, low staleness cost.
Question
What is TTL (Time To Live)?
Click to reveal answer
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