ElastiCache for Redis: Stale Reads on Read Replicas

Consistency Goals in Redis OSS Clusters

When utilizing Amazon ElastiCache for Redis with read replicas, the primary goal is to scale read throughput while maintaining acceptable data freshness. Because replication from the primary node to replicas is asynchronous, there is an inherent risk of stale reads where a client retrieves an older version of a key immediately after a successful write to the primary.

Constraints and Trade-offs

The WAIT command can be used to ensure a write is acknowledged by a specific number of replicas before the client proceeds, reducing the staleness window. However, this introduces increased write latency and can impact overall cluster throughput. There is currently no native configuration flag to enforce strong consistency across all replicas without manually implementing blocking commands in the application logic.

This creates a design uncertainty when balancing high-availability requirements against the need for read-after-write consistency in latency-sensitive environments.

• Is there a documented method to programmatically verify if a specific read replica has caught up to a particular offset before executing a read?
• What are the recommended strategies for monitoring replication lag in real-time to dynamically route critical reads to the primary node?