Availability and durability are different promises

Staying up and not losing data sound like the same virtue. During a regional outage they pull in opposite directions, and a design has to say which one it favours and when.

Availability is about answering: in the CAP sense, every request gets a response. Durability is about remembering: once a commit is acknowledged, the change survives later failures. Losing a region tests both at once, and the cheaper way to keep answering is to give up some remembering. Redis Cluster shows the shape of it. A primary cut off in a minority partition keeps taking writes for a while, a replica on the majority side is promoted, and those writes are gone when the partition heals. That is what Promoting a replica can lose acknowledged writes looks like in practice.

The opposite trade exists too. Kafka can be told to reject writes once too few in-sync replicas remain, keeping acknowledged data on several machines at the price of being partly down. For a user-facing service, serving reads while refusing writes is the most usable form of that choice.

Neither choice is wrong in general, but a claim of tolerance should say which one it made. RTO and RPO name the two costs of an outage gives both sides numbers.