How many replicas would you configure for a shard serving a mission-critical, read-heavy workload, and what does each additional replica cost you?

For a mission-critical, read-heavy workload, the standard answer is replication_factor=2 or 3. Two replicas give you tolerance for a single node failure without an outage and let you distribute read traffic across two copies. Three replicas give you tolerance for two simultaneous node failures and even more read scaling. For most workloads, two replicas is the right default; three is justified when the cost of an outage is very high (financial transactions, medical systems, mission-critical infrastructure) or when the workload must survive two simultaneous failures. Each additional replica costs storage (the replica holds a full copy of the shard's data), compute (the replica runs the same queries if it is used for reads), and write propagation (every write must be applied to every replica, which adds network traffic and latency). The replication factor also affects the Raft quorum: with three replicas, the cluster can tolerate one failure without losing the ability to commit metadata changes.

The mechanism that makes replication valuable for read-heavy workloads is that reads can be distributed across all replicas of a shard, which increases the effective read capacity. With replication_factor=2, you double the read capacity of the shard; with 3, you triple it. This is often more cost-effective than sharding, because it does not add fan-out cost - a read is served by one replica, not by all of them. The write path, however, must propagate every write to every replica, which means the write throughput is bounded by the slowest replica and the network bandwidth between them. The write consistency factor controls how many replicas must acknowledge a write before it is considered successful, which trades write latency for durability. For a read-heavy workload, the write path is not the bottleneck, so the cost of replication is mostly storage and the read capacity benefit is real. For a write-heavy workload, the write propagation cost becomes significant, and the replication factor must be balanced against the write rate.

The trade-off is between availability/read capacity and cost. Each additional replica costs storage, compute, and network bandwidth, so the question is whether the availability and read scaling justify the cost. For a read-heavy workload where reads dominate and writes are infrequent, replication is often cheaper than sharding because it does not add fan-out. For a write-heavy workload, replication is more expensive because every write must be replicated. The common mistakes are: (1) using replication_factor=1 for a mission-critical workload, which means a single node failure causes an outage; (2) using replication_factor=3 when 2 is sufficient, which wastes storage and write bandwidth; (3) not using the replicas for reads, which defeats the read-scaling benefit; (4) not accounting for the write propagation cost in a write-heavy workload; (5) not testing the failover behavior, so the actual recovery time is unknown. Version note: the replication semantics, the write consistency factor, and the failover behavior have evolved across Qdrant releases. The exact behavior during a replica failure and recovery may differ. Test the failover on your version.

Version-dependent: the replication API, the write consistency factor, and the failover behavior have changed across Qdrant releases. Some versions have more sophisticated replica placement and faster failover. Verify the behavior on your version with a forced failure test.