Azure Cache for Redis: Stale Reads from Secondary Replica After Write

Problem Statement

Applications that write to a primary Azure Cache for Redis instance and subsequently read from a secondary replica for read‑scaling can observe stale values because replication is asynchronous. The replication lag can range from milliseconds to seconds, and there is no built‑in mechanism to redirect reads back to the primary immediately after a write.

Constraints & Uncertainty

• Azure Cache for Redis geo‑replication is available only in Premium tier and newer.
• There is no explicit read‑your‑writes guarantee; the feature documentation states that replication is asynchronous.
• Applications must decide whether to read from the primary for a short period after a write or to tolerate eventual consistency.

Specific Questions

1. What Azure Monitor metrics or diagnostic logs can reliably indicate the current replication lag between the primary and secondary replicas?
2. Is there a recommended pattern for temporarily routing read traffic to the primary after a write to ensure read‑your‑writes consistency, and how can that be implemented without significant code changes?
3. During a planned or unplanned failover, what is the maximum data loss window attributable to replication lag, and how can an application detect and recover from that window?