Amazon ElastiCache
In-memory caching service with Valkey, Redis OSS, and Memcached engines
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 Valkey, Redis OSS, or Memcached. Valkey is the open-source Redis fork AWS now leads with; it is cheaper per node, actively developed through 8.x and 9.x, and adds native vector search. Valkey and Redis OSS offer 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
- Three engines: Valkey (the open-source Redis fork and AWS's default), Redis OSS for Redis-specific compatibility, and Memcached (multi-threaded, pure cache, no persistence)
- Valkey and Redis OSS Multi-AZ with automatic failover: a replica is promoted to primary within 20-60 seconds of a primary failure
- Valkey and Redis OSS cluster mode: shards data across up to 500 nodes, increasing aggregate throughput and memory beyond what a single node can provide
- Global Datastore replicates Valkey and Redis OSS clusters across regions for low-latency reads and cross-region disaster recovery
- Encryption in transit (TLS) and at rest, plus engine 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 persistence is enabled). Don't use it as a primary data store. Constraints: Maximum object size is 512MB (Valkey or Redis OSS) or 1MB (Memcached). Valkey and Redis OSS cluster mode have 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 for Valkey as a read-through cache: when a product is requested, the app checks Valkey first. On cache miss, it queries RDS, stores the result in Valkey with a 1-hour TTL, and returns the data. Subsequent requests hit Valkey (sub-millisecond latency), reducing database load by 90%. For session management, they store user sessions in Valkey instead of RDS; sessions are fast, and Valkey 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 Valkey 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.