krzysztof/landing_page
1
0
Fork 0
mirror of https://github.com/qdrant/landing_page.git synced 2026-10-09 21:08:31 +02:00
Code Issues Packages Projects Releases Wiki Activity

Break up "Distributed Deployment" page into new "Scaling & Resilience" section (#2491)

Browse Source 
* Add new Scaling landing page under Operations

Introduces a Scaling section with vertical vs. horizontal scaling
guidance and failover best practices, linking out to detail pages.

* Add new Vertical Scaling page

Dedicated how-to guidance for resizing existing nodes: when to scale
vertically, RAM sizing formulas, and Cloud/self-hosted resize steps.

* Add new Horizontal Scaling and Resilience page

Covers Raft consensus, the replication model, consistency guarantees,
Multi-AZ, and the resilience terminology used elsewhere in the docs.

* Move Distributed Deployment under Scaling and update all incoming links

Moves distributed_deployment.md into the new scaling/ section, trims
its Raft/Replication/Consistency intros into cross-links to the new
Horizontal Scaling and Resilience page, adds Multi-AZ and single-replica
cross-link callouts in the Cloud docs, rewrites all internal references
across ~30 files to the new canonical path instead of relying on
aliases, and applies Title Case to Distributed Deployment's headers.

* Split Resilience out of Horizontal Scaling and Resilience

Adds a dedicated Resilience page covering fault tolerance, Multi-AZ,
resilience terminology, and failover best practices (moved from the
Scaling landing page). Horizontal Scaling is retitled and scoped to
the underlying mechanics: Raft consensus, replication, and consistency.

* Reorganize Horizontal Scaling's structure

Moves "How Many Qdrant Nodes Should I Run?" from Distributed Deployment
into Horizontal Scaling, adds a conceptual Sharding section, and
reorders Sharding/Replication/Raft Consensus/Consistency. Moves the
remaining conceptual content out of Distributed Deployment: Temporary
Node Failure to Resilience, Error Handling folded into Replication,
sharding heuristics folded into Sharding, and the Consensus
Checkpointing explanation folded into Raft Consensus.

* Rename Scaling section to Scaling & Resilience

Renames the section and restructures the landing page: the vertical-
vs-horizontal decision is now purely about scaling, with a dedicated
Resilience section covering fault tolerance through sharding and
multi-node deployments.

* Polish Vertical Scaling and Resilience page content

Reframes Vertical Scaling's "What Not to Do" as positive "Best
Practices". Reworks Resilience's structure: moves the uptime/data-
integrity terminology into the intro as three distinct aspects of
resilience, and renames "How Resilience Works" to "Setting Up a
Resilient Qdrant Cluster".

* Add diagrams illustrating sharding and replication

Adds cluster diagrams to the Sharding and Replication sections on
Horizontal Scaling to make the shard/replica layout easier to follow.

* Add new Node Failure Recovery page

Extracts the node failure recovery scenarios out of Distributed
Deployment into their own page, with each bolded sub-header converted
to a proper heading, and links updated across Resilience and the
Scaling landing page.

* Add new Consistency Guarantees page

Extracts write consistency factor, read consistency, and write
ordering out of Distributed Deployment into their own page, positioned
after Distributed Deployment.

* Add new "Deploy Behind a Load Balancer" section

Explains why a load balancer is needed in front of a multi-node
Qdrant cluster: avoiding a single point of failure at the entry point
and making sure replicas on every node actually serve reads.

* Add new "Rebalancing" section

Documents how Qdrant Cloud automatically rebalances shards across
nodes, as its own subsection under Sharding.

* Rewrite Multi-AZ vs. Replication Factor as Multi-AZ Deployments

Defines an availability zone on first use, explains why multi-AZ
deployments guard against a zone going down, clarifies that Qdrant
Cloud is zone-aware once enabled, and that self-hosted deployments
need to place and move replicas across zones manually.

* Restructure node-count guidance into One/Two/Three-or-more Node subsections

Splits "How Many Qdrant Nodes Should I Run?" into three subsections
and drops the "balanced" framing for two nodes: it states plainly
that two nodes give more capacity without true high availability.

* Add new "Which Configuration Is Right for You?" section

Summarizes the one/two/three-or-more node tradeoffs in one place
right after the detailed breakdown.

* Add explicit _redirects entry for legacy distributed_deployment URL

Closes the redirect chain: the existing /guides/ and /operations/
legacy rules both terminate at /documentation/distributed_deployment/,
which previously had no explicit _redirects entry and only resolved
via the Hugo alias meta-refresh page.

* Fix all incoming links to Distributed Deployment and pages under Scaling

Repoints two same-page anchors in distributed_deployment.md that broke
when Write Ordering moved to Consistency Guarantees, and one link in
cloud/create-cluster.md that broke when a Resilience heading was
reworded.

* Update time-based sharding diagram and restructure section

* Fix a couple of broken links

* Move 'Consensus Checkpointing' to 'Node Failure Recovery' page
This commit is contained in:
Abdon Pijpelink
2026-07-16 09:11:58 +02:00
committed by GitHub
parent e413d5107c
commit 45f19f30ee
45 changed files with 1620 additions and 1405 deletions
Download Patch File Download Diff File Expand all files Collapse all files
qdrant-landing/content/articles/vector-search-production.md
+6 -6
View File
@@ -243,7 +243,7 @@ It depends. If you're just starting out - we have prepared a tool on our website
A three-node setup provides a baseline for fault tolerance: if one node goes offline, the remaining two can continue serving queries and maintain a quorum for data consistency. This guards against hardware failures, rolling updates, and network disruptions. Fewer than three nodes leaves you vulnerable to single-point failures that can knock your entire cluster offline.
> [**We follow the Raft Protocol**](https://qdrant.tech/documentation/distributed_deployment/#raft), so check out the docs and learn why this is important.
> [**We follow the Raft Protocol**](https://qdrant.tech/documentation/scaling/horizontal-scaling/#raft-consensus), so check out the docs and learn why this is important.
✅ **Set a replication factor of at least 2** to tolerate node failure without losing availability.
@@ -275,7 +275,7 @@ Development and staging environments often run experimental builds, tests, or si
> It's quite possible that the user has multiple shards on one node, which end up handling most traffic while other nodes remain underutilized.
In this case, you should [**choose the right number of shards**](https://qdrant.tech/documentation/distributed_deployment/#sharding) based on your node count and expected RPS.
In this case, you should [**choose the right number of shards**](https://qdrant.tech/documentation/scaling/distributed_deployment/#sharding) based on your node count and expected RPS.
You need to implement a shard strategy that aligns with real usage patterns. First, distribute your shards across all available nodes. This will help balance the load more effectively. After redistributing the shards, run performance tests to see how it affects your system. Then add replicas and test again to see how that changes performance.
@@ -286,14 +286,14 @@ Proper sharding considers data distribution and query patterns. By default, shar
||
|-|
|**Read More:** [**Sharding Documentation**](https://qdrant.tech/documentation/distributed_deployment/#sharding)|
|**Read More:** [**Sharding Documentation**](https://qdrant.tech/documentation/scaling/distributed_deployment/#sharding)|
### Manage Your Costs by Scaling Up or Down
![vector-search-production](/articles_data/vector-search-production/vector-search-production-5.jpg)
Some teams scale up for daytime surges, then scale down overnight to save resources. If you do this, ensure data is sharded and replicated appropriately, so that scaling up and down won't result in service degradation.
If using Qdrant Cloud you could also do this using the [**Replication Factor**](https://qdrant.tech/documentation/distributed_deployment/#replication-factor), though it may be considered a bit of a hack.
If using Qdrant Cloud you could also do this using the [**Replication Factor**](https://qdrant.tech/documentation/scaling/distributed_deployment/#replication-factor), though it may be considered a bit of a hack.
> If you have 3 nodes with just 1 shard, and replication factor 6. It will create 3 replicas (one on each node) of that shard, because it can't host more. If you add 3 more nodes at peak times, it'll automatically replicate that shard 3 more times in an attempt to match the factor of 6.
@@ -309,7 +309,7 @@ If new nodes remain empty after joining, you waste resources. If departing nodes
||
|-|
|**Read More:** [**Distributed Deployment Documentation**](https://qdrant.tech/documentation/distributed_deployment/)|
|**Read More:** [**Distributed Deployment Documentation**](https://qdrant.tech/documentation/scaling/distributed_deployment/)|
|**Read More:** [**Resharding**](https://qdrant.tech/documentation/cloud/cluster-scaling/#resharding)|
### How to Predict and Test Cluster Performance
@@ -332,7 +332,7 @@ Remember, cold-starts and query behaviour are dataset dependent, which is why yo
||
|-|
|**Read More:** [Distributed Deployment Documentation](https://qdrant.tech/documentation/distributed_deployment/)
|**Read More:** [Distributed Deployment Documentation](https://qdrant.tech/documentation/scaling/distributed_deployment/)
### How to Design Your Systems to Protect Against Failure