How does Qdrant handle consistency during a node failure?

Qdrant's fault tolerance during a node failure relies on the combination of shard replication and Raft-based consensus: as long as enough replicas of each shard and enough cluster nodes remain available, the cluster continues operating correctly despite the lost node.

For data operations (reads and writes to points), Qdrant supports configurable consistency levels — a write can be configured to require acknowledgment from a majority of a shard's replicas before being considered successful, and reads can similarly be tuned between favoring availability (reading from any available replica, potentially slightly stale) and favoring strict consistency (requiring a majority read to guarantee the most up-to-date data).

For cluster-wide metadata (collection configuration, shard assignments), the Raft protocol's majority-based commit guarantee is what keeps that state consistent even through node failures and leader re-elections; as long as a majority of cluster nodes remain reachable, the cluster can continue accepting new metadata changes and, once a failed node recovers or is replaced, it catches up by replaying the Raft log to rejoin the cluster with a consistent view of state.