Witness and tiebreaker replicas
What does a voting-only replica save, and what does it cost when a data replica is lost?
Quorum systems need an odd count for the majority arithmetic. But the reason is voting, not data. These two are separable, and separating them is the cheapest trick in this article.
A witness takes part in elections and quorum counting while storing metadata only: votes without bytes. Two full copies plus a witness tolerate one failure with majority safety at about 2× storage instead of 3×. That is a 33% saving on the largest line item in any storage system. This is why the pattern appears independently in relational high availability, object stores and cloud database services.
This is Management's question at Mediflow: Nairobi-1 and Nairobi-2 as full copies, plus a witness in a small third site, Mombasa. Two honest boundaries answer it.
A witness reduces storage cost, not availability risk
With two full copies and a witness, losing one data replica leaves exactly one copy of the data. The system is still available, because the witness plus the survivor form a majority. But it now has zero redundancy. The recovery window is the time to rebuild a full replica: data volume ÷ rebuild bandwidth, which is measured in hours. During that window, a second failure is total loss.
- Three full copies degrade to two copies.
- Two copies plus a witness degrade to one copy.
That is the real difference. It appears neither in the cost table nor in the availability target.
Placement is the entire design
A witness exists to break ties between two sites, so it must be in a third failure domain. A witness placed in one of the two data sites makes that site's failure unsurvivable (the other site alone is a minority) and the other site's failure survivable. This asymmetry is invisible until the wrong site dies. It is the clearest case where a mechanism's correctness is entirely a placement property and not a protocol property.