Amazon ElastiCache
In-memory caching service supporting Redis and Memcached
ElastiCache is like having a super-fast memory assistant who remembers things you've looked up recently so you don't have to go back to the slow filing cabinet (database) every time. When your application needs data, it checks ElastiCache first; if it's there (a cache hit), you get it in microseconds. If not (a cache miss), you fetch it from the database and store a copy in ElastiCache for next time. It's perfect for things like session data, frequently accessed database queries, or API responses. Think of it as short-term memory that's lightning fast but doesn't store everything forever, just the hot data you need right now.
ElastiCache provides fully managed in-memory data stores using Redis or Memcached. Redis offers advanced features: data persistence, replication, automatic failover, pub/sub messaging, and complex data structures (lists, sets, sorted sets). Memcached is simpler: pure caching with multi-threaded performance.
Key Capabilities
- Supports two engines: Redis (persistence, replication, complex data structures, pub/sub, Lua scripting) and Memcached (multi-threaded, pure cache, no persistence)
- Redis Multi-AZ with automatic failover: a replica is promoted to primary within 20-60 seconds of a primary failure
- Redis cluster mode: shards data across up to 500 nodes, increasing aggregate throughput and memory beyond what a single node can provide
- Global Datastore for Redis: cross-region replication for low-latency reads and cross-region disaster recovery
- Encryption in transit (TLS) and at rest, plus Redis AUTH tokens for access control within the VPC
- Memcached auto-discovery: clients automatically detect node additions and removals without manual reconfiguration
Gotchas & Constraints
Gotcha #1: Cache invalidation is hard; stale data in cache can cause bugs. Implement TTLs (time-to-live) and cache invalidation strategies (write-through, write-behind). Gotcha #2: ElastiCache is in-memory; data is lost if nodes fail (unless using Redis with persistence). Don't use it as a primary data store. Constraints: Maximum object size is 512MB (Redis) or 1MB (Memcached). Redis cluster mode has limitations (no multi-key operations across shards).
An e-commerce site queries product details from RDS PostgreSQL on every page load; database CPU hits 80%, and page load times reach 2 seconds. They implement ElastiCache Redis as a read-through cache: when a product is requested, the app checks Redis first. On cache miss, it queries RDS, stores the result in Redis with a 1-hour TTL, and returns the data. Subsequent requests hit Redis (sub-millisecond latency), reducing database load by 90%. For session management, they store user sessions in Redis instead of RDS; sessions are fast, and Redis Multi-AZ replication ensures high availability. During flash sales, they pre-warm the cache with popular products, handling 10,000 requests/second without touching the database. They use Redis pub/sub to invalidate cache entries when products are updated.
The Result
page load times drop to 200ms, database CPU drops to 20%, and the site handles 5x more traffic.