Amazon ElastiCache provides managed in-memory caches—Redis or Memcached—to speed read-heavy apps by storing hot data outside the primary database.
Cache patterns
- Cache-aside — app reads cache, on miss loads DB and populates cache
- TTL — expire keys to limit stale data
- Session store — Redis for shared sessions across EC2 instances
Redis vs Memcached
| Redis | Memcached |
|---|---|
| Rich data structures, persistence options | Simple key-value, multi-threaded |
| Pub/sub, sorted sets | Horizontal scale out simple |
Placement
Run ElastiCache in private subnets; security group allows app tier on port 6379 (Redis). Never expose cache endpoints to the public internet.
Preview CLI
aws elasticache describe-cache-clusters \
--query 'CacheClusters[].{Id:CacheClusterId,Engine:Engine,Status:CacheClusterStatus}' \
--output tablePractice: Use RDS and DynamoDB free tier where eligible. Delete sandbox databases when finished—storage and instance hours can incur charges.
Important interview questions and answers
- Q: Cache-aside flow?
A: App checks cache first; on miss queries DB and writes result to cache with TTL. - Q: Why in-memory?
A: Sub-millisecond reads vs disk-backed databases—trade memory cost for latency.
Self-check
- Describe cache-aside in three steps.
- Why place ElastiCache in a private subnet?
Tip: Always set TTL on cache keys—stale session data causes confusing bugs.
Interview prep
- Cache-aside?
App reads cache; on miss loads DB and writes entry with TTL.
- Redis vs Memcached?
Redis richer structures and persistence; Memcached simple multi-threaded cache.