Scaling, Availability & When Caching Isn't the Fit

Replication Groups & Automatic Failover

A Redis replication group gives a primary node one or more read replicas, supporting read scaling and automatic failover — if the primary fails, ElastiCache can promote a replica automatically, minimizing downtime versus manual recovery.

Cluster Mode & Serverless

Cluster mode shards the keyspace across multiple node groups, scaling total dataset size and write throughput beyond a single node's limits. ElastiCache Serverless removes manual capacity planning entirely, scaling automatically with actual usage — useful for workloads with variable or hard-to-predict traffic.

Eviction Policy & Memory Pressure

When a node hits its memory limit, an eviction policy (commonly LRU — least recently used) determines which existing entries get removed to make room for new ones, rather than the cache simply refusing new writes.

Network Isolation & Session Stores

ElastiCache clusters run inside a VPC, reachable only from resources explicitly allowed via security groups — never exposed to the public internet by default. A common use case: storing session data in Redis so any application server behind a load balancer can serve a given user's request, avoiding sticky sessions pinned to one specific server.

The Cache Is Not the Source of Truth

Cache data can be evicted due to memory pressure, TTL expiration, or node failure — it should be reconstructable from the underlying database, which remains durable. And for data that must be perfectly up to date on every single read, caching offers limited benefit: it would need near-constant invalidation, undermining the performance gain it's meant to provide.