Why doesn't Redis guarantee strong consistency by default across replicas?

Redis's default replication is asynchronous specifically to keep write latency low: a master acknowledges a write as soon as it's processed locally, without pausing to confirm every replica has received it too. That design choice is exactly what makes strong consistency (every replica always reflecting the latest acknowledged write) not guaranteed by default — there's an inherent window, however small, where a replica's data can be behind the master's.

The practical consequence shows up most visibly during failover: if a master fails and a replica that hadn't yet received the most recent writes is promoted (by Sentinel or Redis Cluster), those most recent writes are permanently lost, and any client that had already read them from the old master before the failure effectively saw data that no longer exists post-failover. This is a deliberate trade-off, not an oversight — Redis prioritizes latency and availability over strict consistency by default, which fits the vast majority of caching and session-storage use cases where slightly stale replica reads or an occasional lost write during a rare failover are an acceptable cost.

For workloads that need stronger guarantees, the WAIT command (blocking until a specified number of replicas acknowledge a given write) is the available lever, used selectively for specific critical writes rather than as a blanket default, since applying it to every write would erode the latency benefit that makes Redis attractive in the first place.