Flash card
Caching with ElastiCache versus adding a read replica: both shed read load, for different read shapes.
- A read replica serves the same queries against the same schema, so existing read traffic can be repointed with a connection-string change and no application logic.
- ElastiCache serves from memory in microseconds, but only for keys the application decides to cache, so it needs code that reads through and invalidates.
- Replica lag is the replica’s consistency cost; a stale cache entry is the cache’s, and the cache’s is controlled by a TTL you choose.
- A cache absorbs a hot key that a replica cannot, because every replica read of the same row still costs a query.
- Aurora replicas share the cluster storage volume, so their lag is typically far lower than a classic RDS read replica’s.
Pick it when
Pick a read replica when a broad spread of read queries needs somewhere to go and you cannot change the application. Pick ElastiCache when a small set of keys is read repeatedly and microsecond latency matters.
It's the wrong answer when
Neither is the answer to a write bottleneck, and a read replica is the wrong answer when the scenario needs read-after-write consistency. A cache is the wrong answer when every read is unique, because the hit rate never climbs and you have added a component for nothing.