8.2 Caching Strategies and ElastiCache Patterns

Quick Answer: Lazy loading = cache-aside (check cache; on miss read DB, fill cache, return). Write-through = write cache + DB together (never stale, but write overhead). TTL auto-expires entries. Use Redis for persistence, Multi-AZ failover, sorted sets, and pub/sub; use Memcached for simple multi-threaded key-value caching. Move sessions into Redis to make app servers stateless and scale horizontally.

Caching Strategies

Lazy Loading (Cache-Aside)

1. App checks the cache.
2. Hit → return cached data (fast).
3. Miss → read the database, write the result to cache, return.

Write-Through

The app writes to cache AND database on every write, so reads always hit fresh data.

Recommended combined pattern

Use lazy loading + write-through + TTL together: write-through keeps actively updated keys fresh, lazy loading populates read-only keys on demand, and TTL caps staleness and reclaims memory. The exam treats 'minimize stale data' as a write-through signal and 'reduce read latency / offload the database' as a lazy-loading signal.

Choosing a TTL

Common Trap: A 'thundering herd' happens when a popular key expires and many requests miss simultaneously and stampede the database. Mitigate with slightly randomized (jittered) TTLs or pre-warming hot keys.

Session Store Pattern

Keeping session state on individual EC2 instances forces ALB sticky sessions and loses carts when an instance fails or scales in.

On the Exam: 'Make app servers stateless for Auto Scaling' → store sessions in ElastiCache for Redis (or DynamoDB). 'Reduce repeated identical database reads' → add ElastiCache with lazy loading.

Redis vs. Memcached

ElastiCache offers three engines: Redis OSS, Valkey (an open-source Redis fork AWS now offers at lower cost), and Memcached. For the exam, the decisive split is Redis-family (rich features) vs Memcached (simple).

Key exam tells: leaderboard / ranking → Redis sorted sets; persistence or failover → Redis; simplest possible cache, multi-threaded → Memcached.

Cache Invalidation

Beyond ElastiCache

ElastiCache is in-memory caching for application-tier data and sessions. Do not confuse it with DynamoDB Accelerator (DAX), an in-memory cache specific to DynamoDB that requires no application code change, or with CloudFront, which caches HTTP responses at edge locations. A 'cache DynamoDB reads with microsecond latency and no code change' scenario points to DAX, not ElastiCache.

Worked Example: Sizing a Read-Heavy Cache

Suppose a product-catalog page is read 10,000 times per second but the underlying items change only a few times per hour. Without caching, every request hits RDS, forcing a large, expensive instance and read replicas just to survive. Add ElastiCache for Redis with lazy loading and a 5-minute TTL: after the cache warms, the cache-hit ratio approaches 99%, so RDS sees roughly 100 reads/second instead of 10,000. The database can shrink, replication lag disappears, and p99 read latency drops from tens of milliseconds to sub-millisecond. This is the canonical 'reduce database load and latency' answer.

Now contrast a checkout-price scenario where a stale price for even seconds is unacceptable. Here lazy loading alone is risky; pair write-through (update the cache whenever the price is written) with a short TTL as a safety net. The pattern you choose is dictated by the staleness tolerance stated in the question.

Multi-AZ and Failover Details

For Redis, a replication group has one primary and up to five read replicas across AZs. With Multi-AZ enabled, ElastiCache automatically promotes a replica to primary on failure and updates the primary endpoint DNS — typically within seconds. Memcached has no replication or failover; a lost node simply loses its slice of cached data, which is acceptable only for pure caches that can repopulate from the database. If a question demands cache durability or automatic failover, Memcached is eliminated immediately.