Caching to Reduce Database Load

Purpose: Fully managed in-memory caching service that reduces database load and improves application performance

Pricing Components:

• Node Hours: Per-hour charge based on node type (cache.t3.micro to cache.r6g.16xlarge)
• Data Transfer: Data transferred out of ElastiCache (in-region transfer is free)
• Backup Storage: Automated backups beyond free allocation (Redis only)

Pricing Examples (US-East-1, On-Demand):

• cache.t3.micro: $0.017/hour (~$12.41/month)
• cache.r6g.large: $0.136/hour (~$99.28/month)
• cache.r6g.xlarge: $0.272/hour (~$198.56/month)
• cache.r6g.2xlarge: $0.544/hour (~$397.12/month)

Reserved Node Savings:

• 1-year reservation: Up to 31% savings
• 3-year reservation: Up to 55% savings

Cost Comparison Example:

Before Caching (RDS MySQL):

• db.r6g.2xlarge: $0.96/hour = ~$700/month
• Multi-AZ: $1.92/hour = ~$1,400/month
• Read Replicas (3x): Additional ~$2,100/month
• Total: ~$3,500/month

After Caching (80% cache hit ratio):

• ElastiCache (cache.r6g.large, 2 nodes): ~$200/month
• RDS downsized to db.r6g.large: $0.48/hour = ~$350/month
• Multi-AZ: ~$700/month
• Read Replicas reduced to 1: ~$350/month
• Total: ~$1,600/month

Monthly Savings: ~$1,900 (54% reduction)

Key Insight: Cache node cost (~$200) enables RDS savings (~$2,100) - a 10:1 return on cache investment

High ROI Scenarios:

• Read-heavy workloads (70%+ reads)
• Frequently accessed data (hot spots)
• Data that changes infrequently
• Complex database queries that can be cached
• High database instance costs

Low ROI Scenarios:

• Write-heavy workloads
• Data that changes every request
• Highly random access patterns (no hot spots)
• Very small databases already on minimum instance sizes

Break-Even Analysis:

• If cache hit ratio < 50%, savings may not justify cache cost
• If database is already minimal size, no room to downsize
• Consider operational complexity costs

Purpose: Fully managed, highly available, in-memory cache specifically designed for DynamoDB

Key Characteristics:

• Microsecond response times (vs milliseconds for DynamoDB)
• API-compatible with DynamoDB (minimal code changes)
• Write-through cache (writes go to both cache and DynamoDB)
• Handles cache invalidation automatically
• Cluster-based deployment (3+ nodes for production)

DAX vs ElastiCache for DynamoDB:

• DAX: Purpose-built, API-compatible, automatic cache management
• ElastiCache: More flexible, requires application-level cache logic
• DAX: Best for simple caching of DynamoDB reads
• ElastiCache: Best for complex caching patterns, session storage

Pricing Components:

• Node Hours: Per-hour charge based on node type
• Data Transfer: Free within same AZ, charges for cross-AZ
• No separate charge for storage (in-memory only)

Pricing Examples (US-East-1, On-Demand):

• dax.t3.small: $0.04/hour (~$29.20/month)
• dax.r5.large: $0.269/hour (~$196.37/month)
• dax.r5.xlarge: $0.538/hour (~$392.74/month)
• dax.r5.2xlarge: $1.076/hour (~$785.48/month)

Minimum Production Setup (3 nodes):

• 3x dax.r5.large: ~$589/month

Reserved Capacity Savings:

• 1-year: Up to 35% savings
• 3-year: Up to 55% savings

Scenario: High-traffic application with 100,000 reads/second

Without DAX (On-Demand DynamoDB):

• Eventually consistent reads: 50,000 RRUs (100K reads / 2)
• Cost: 50,000 * $0.00013/RRU/hour = $6.50/hour
• Monthly: ~$4,745

With DAX (90% cache hit ratio):

• DAX cluster (3x dax.r5.large): ~$589/month
• DynamoDB reads reduced to 10,000/second
• DynamoDB cost: 5,000 RRUs = ~$475/month
• Total: ~$1,064/month

Monthly Savings: ~$3,681 (78% reduction)

Break-Even Point: DAX pays off when read traffic justifies cluster cost

• Minimum viable: ~15,000+ reads/second for r5.large cluster

Definition: The percentage of read requests served from cache vs total read requests

Formula: Cache Hit Ratio = (Cache Hits) / (Cache Hits + Cache Misses) * 100

Impact on Cost Savings: | Hit Ratio | DB Load Reduction | Typical Savings | |-----------|------------------|-----------------| | 50% | 50% | 20-30% cost reduction | | 70% | 70% | 40-50% cost reduction | | 80% | 80% | 50-60% cost reduction | | 90% | 90% | 60-75% cost reduction | | 95% | 95% | 70-80% cost reduction |

Industry Benchmarks:

• Minimum acceptable: 70%
• Good: 80-90%
• Excellent: 90-95%
• World-class: 95%+

1. Cache Warming:

• Pre-populate cache before traffic spikes
• Load frequently accessed data at startup
• Use scheduled jobs to refresh popular items

2. Appropriate TTL Settings:

• Too short: Low hit ratio, frequent DB calls
• Too long: Stale data, memory pressure
• Tune based on data change frequency

3. Key Design:

• Use consistent, predictable key patterns
• Include version numbers for cache invalidation
• Avoid overly granular keys (reduces hit probability)

4. Right-Size Cache Memory:

• Monitor eviction rates
• If evictions high, increase memory or reduce TTL
• Use CloudWatch MemoryUsage and Evictions metrics

5. Data Structure Optimization:

• Cache aggregated/computed results (not raw data)
• Use appropriate data structures (strings, hashes, sorted sets)
• Compress large values to fit more in memory

Key CloudWatch Metrics for ElastiCache:

Hit Ratio Metrics:

• CacheHits: Number of successful cache reads
• CacheMisses: Number of cache misses
• CacheHitRate: Percentage of hits (calculated)

Capacity Metrics:

• BytesUsedForCache: Memory currently used
• Evictions: Number of items evicted due to memory pressure
• CurrConnections: Current client connections
• NewConnections: New connections per second

Health Metrics:

• CPUUtilization: Node CPU usage
• NetworkBytesIn/Out: Network throughput
• ReplicationLag: Replica sync delay (Redis)

Alarm Thresholds:

• Cache hit ratio < 70%: Investigate access patterns
• Evictions > 0 sustained: Increase memory
• CPU > 65%: Consider scaling

Purpose: Automatically expire cached data to ensure freshness and manage memory

How TTL Works:

• Set expiration time when caching data
• Cache automatically removes expired items
• Next request triggers cache miss and fresh data fetch

TTL Trade-offs:

• Short TTL (seconds to minutes): Fresh data, lower hit ratio, more DB load
• Long TTL (hours to days): Higher hit ratio, potentially stale data
• No TTL: Maximum hit ratio, manual invalidation required

Cost Impact:

• Shorter TTL = more database calls = higher database costs
• Longer TTL = fewer database calls = lower database costs
• Balance freshness requirements with cost optimization

Static Configuration Data (Hours to Days):

• Application settings
• Feature flags
• Reference data (countries, categories)
• TTL: 1-24 hours

User Profile Data (Minutes to Hours):

• User preferences
• Account information
• Permissions/roles
• TTL: 5-60 minutes

Session Data (Minutes):

• Shopping carts
• Authentication tokens
• Form state
• TTL: 15-30 minutes

Real-Time Data (Seconds):

• Stock prices
• Live scores
• Inventory counts
• TTL: 5-60 seconds

Computed Results (Variable):

• Search results
• Aggregations
• Reports
• TTL: Based on underlying data change frequency

Staggered TTL:

• Add random jitter to prevent thundering herd
• Example: Base TTL 60s + random(0-30s)
• Prevents all caches expiring simultaneously

Sliding TTL:

• Reset TTL on each access
• Keeps hot data in cache longer
• Reduces DB load for popular items

Adaptive TTL:

• Adjust TTL based on access patterns
• Popular items: Longer TTL
• Rarely accessed: Shorter TTL
• Requires custom implementation

Cache Tags:

• Group related cache entries
• Invalidate entire groups at once
• Example: All user-123 related caches

How It Works:

1. Application checks cache first
2. If cache hit: Return cached data
3. If cache miss: Query database
4. Store result in cache
5. Return data to caller

Advantages:

• Only requested data is cached
• Cache failures don't break application
• Simple to implement
• Works with any database

Disadvantages:

• First request always hits database
• Application manages cache logic
• Potential for stale data
• Cache misses add latency (cache check + DB call)

Best For:

• General-purpose caching
• Applications with unpredictable access patterns
• When database can handle cache miss spikes

How It Works:

1. Application always reads from cache
2. Cache automatically fetches from database on miss
3. Cache manages data loading logic
4. Application code simplified

Advantages:

• Simpler application code
• Consistent cache population logic
• Cache handles database interaction
• Better abstraction

Disadvantages:

• Cache becomes critical path
• More complex cache infrastructure
• Limited flexibility in fetch logic
• May cache unnecessary data

Best For:

• Standardized data access patterns
• When cache infrastructure can handle load
• Reducing application complexity

AWS Implementation: DAX is a read-through cache for DynamoDB

How It Works:

1. Application writes to cache
2. Cache synchronously writes to database
3. Both updated before confirming write
4. Read always from cache

Advantages:

• Cache always has latest data
• No stale data issues
• Simplified read path
• Consistent data

Disadvantages:

• Write latency increased
• Cache failures can block writes
• All data cached (even if never read)
• Higher cache memory usage

Best For:

• Read-heavy workloads
• Data that must always be fresh
• When write latency is acceptable

AWS Implementation: DAX uses write-through for DynamoDB

How It Works:

1. Application writes to cache only
2. Cache acknowledges immediately
3. Cache asynchronously writes to database
4. Batches writes for efficiency

Advantages:

• Fastest write performance
• Reduced database write load
• Batching improves efficiency
• Lower database costs

Disadvantages:

• Risk of data loss if cache fails
• Eventual consistency
• Complex failure handling
• Not suitable for critical data

Best For:

• Write-heavy workloads
• When some data loss is acceptable
• Analytics and logging
• Non-critical updates