8.2 Caching Strategies and ElastiCache Patterns
Key Takeaways
- Lazy Loading (Cache-Aside) reads from cache first; on a miss, reads from the database, writes to cache, then returns — simple but causes initial cold-start latency.
- Write-Through writes to cache and database simultaneously — data is always up-to-date in cache but adds write latency and may cache unused data.
- TTL (Time-to-Live) helps balance between stale data and cache misses — set TTL based on how frequently your data changes.
- ElastiCache for Redis supports complex data structures, persistence, replication, and pub/sub; Memcached is simpler and multi-threaded for basic caching.
- Session store pattern: store user sessions in ElastiCache Redis to enable stateless application servers that can scale horizontally.
Caching Strategies and ElastiCache Patterns
Quick Answer: Lazy Loading = cache-aside (read from cache, on miss read DB + fill cache). Write-Through = write to cache + DB simultaneously. TTL = auto-expire cached data. Use Redis for rich features + persistence. Use Memcached for simple, high-throughput caching. Session stores in Redis enable stateless horizontal scaling.
Caching Strategies
Lazy Loading (Cache-Aside)
How it works:
- Application checks cache first
- Cache hit: Return cached data (fast)
- Cache miss: Read from database → write result to cache → return data
| Advantage | Disadvantage |
|---|---|
| Only requested data is cached | Cache miss = slower (extra round trip) |
| Cache failure does not break the application | Stale data possible (no automatic updates) |
| Simple to implement | Cold start: first request always misses |
Write-Through
How it works:
- Application writes to cache AND database simultaneously
- Every read hits the cache (always up-to-date)
| Advantage | Disadvantage |
|---|---|
| Data in cache is never stale | Every write has extra cache write overhead |
| Reads are always fast (cache hit) | Unused data may consume cache space |
| Cache failure means write failure (if synchronous) |
Combined Strategy (Recommended)
Use Lazy Loading + Write-Through + TTL together:
- Write-Through keeps actively written data up-to-date
- Lazy Loading fills the cache for reads
- TTL expires data that has not been updated, preventing unlimited cache growth
TTL (Time-to-Live) Considerations
| Data Change Frequency | Recommended TTL |
|---|---|
| Real-time (stock prices) | Seconds (5-30) |
| Frequently changing (product inventory) | Minutes (1-15) |
| Slowly changing (user profiles) | Hours (1-24) |
| Rarely changing (static content) | Days (1-7) |
Session Store Pattern
Store user sessions in ElastiCache instead of on application servers:
Without ElastiCache:
- Sessions stored on individual app servers
- Sticky sessions required (ALB ties user to specific server)
- Losing a server loses all sessions on it
With ElastiCache (Redis):
- Sessions stored in centralized Redis cache
- Any app server can serve any user
- Losing an app server does not lose sessions
- App servers are stateless → scale freely with Auto Scaling
On the Exam: "Make application servers stateless for horizontal scaling" → Store sessions in ElastiCache Redis (or DynamoDB). "Reduce database read latency" → Add ElastiCache with Lazy Loading.
Redis vs. Memcached Decision
| Choose Redis When | Choose Memcached When |
|---|---|
| Need data persistence | Simple key-value caching only |
| Need Multi-AZ failover | Maximum simplicity |
| Need complex data types (lists, sets, sorted sets) | Multi-threaded performance needed |
| Need pub/sub messaging | No replication/failover needed |
| Need sorted sets for leaderboards | Pure caching (no persistence) |
| Need geospatial data support | |
| Need Lua scripting |
Cache Invalidation
| Method | How | Use Case |
|---|---|---|
| TTL | Cache entries auto-expire | General (most common) |
| Explicit delete | Application deletes cache key on update | When data changes are known |
| Event-driven | DynamoDB Streams / SNS triggers cache update | Real-time consistency |
An application has a read-heavy database workload. The team wants to add caching but is concerned about serving stale data. Which caching strategy minimizes stale data?
A web application needs to scale horizontally with Auto Scaling, but users are losing their sessions when they are routed to different servers. How should this be fixed?