Questions
3 of 11
1Evaluate this claim: 'Cosine similarity and normalized dot product always produce identical rankings.' What subtlety do candidates often miss here?
2Many candidates assume increasing ef at query time always improves recall with only a linear latency cost. What's misleading about that assumption?
3Why is 'just add more RAM' not always a valid answer to a Qdrant performance question in a system design interview?
4A candidate claims that quantization always speeds up search. Under what conditions might quantization with rescoring actually be slower than searching un-quantized vectors?
5Why can two identical-looking filter queries - one using an indexed field, one using an equivalent but unindexed field - have wildly different performance, even though they return the same results?
6At billion-point scale, how would your indexing and sharding strategy differ from a design that works fine at ten million points?
7How would you architect a system to gracefully degrade - rather than fail outright - when a burst of traffic exceeds provisioned Qdrant capacity?
8What are the limits of a purely payload-filter-based multitenancy model, and at what point would you need to introduce dedicated shards or collections per tenant instead?
9How would you approach re-embedding a multi-billion-point production collection with a new embedding model with zero search downtime?
10When designing a retrieval system that combines dense, sparse, and multivector reranking at extreme scale, what's the single biggest cost driver you'd optimize first, and why?
11If you were asked to design Qdrant's filtered-HNSW search from scratch, what core problem would you need to solve, and what naive approach would you reject first?
QdrantQdrant
Core Concepts
Setup and Basic Use
QueryAPIs
Named Vectors and Multitenancy
Sparse Vectors and Hybrid Search
Snapshots and Backups
Indexing Internals
Internal Architecture
Performance and Optimisation
Security
Error Handling and Debugging
Testing
Design Patterns
Implementation Scenarios
System Design and Scalability
Edge Cases
03 / 11

Why is 'just add more RAM' not always a valid answer to a Qdrant performance question in a system design interview?

The bottleneck may not be memory; adding RAM has a cost and a ceiling

The answer 'add more RAM' is a valid answer only when the bottleneck is memory-bound and the deployment can scale vertically. In a system design interview, it is usually a signal that the candidate has not diagnosed the bottleneck. The first reason it is not always valid is that the bottleneck may be CPU, I/O, network, or the coordinator, not memory. A query that is CPU-bound on distance computations will not get faster with more RAM. A query that is limited by the coordinator's merge work will not get faster with more RAM. A query that is limited by network round trips between nodes will not get faster with more RAM. The second reason is that vertical scaling has a ceiling: the largest machine available may not be enough, and the cost per unit of RAM grows super-linearly at the top end. The third reason is that adding RAM to a single node does not help if the data is sharded across nodes: the query still fans out, and the slowest shard bounds the latency. The fourth reason is that adding RAM may not address the actual cost driver, which could be the optimizer competing for resources, a suboptimal index configuration, or an inefficient query pattern. The right answer starts with diagnosing the bottleneck, then choosing the lever that addresses it.

The mechanism that makes 'add more RAM' appealing but often wrong is that RAM is the most visible resource and the one that most directly affects page-cache hit rate, which is a common cause of tail latency. So there are real cases where adding RAM is the right answer: an on-disk collection whose working set does not fit in cache, where adding RAM increases the hit rate and reduces p99. But those cases must be diagnosed, not assumed. The diagnosis is to measure the bottleneck: CPU utilization, disk I/O, network, page-cache hit rate, coordinator latency, and the distribution of query latency. If CPU is saturated and disk is idle, the bottleneck is CPU. If disk is saturated and CPU is idle, the bottleneck is I/O. If both are moderate and latency is high, the bottleneck may be the coordinator or the network. Only after identifying the bottleneck can you choose the lever. The levers include: reducing ef (CPU), reducing the working set with quantization (memory), sharding (distribution), adding replicas (read capacity), tuning the optimizer (background contention), and improving the query pattern (fewer candidates, better filters). Adding RAM is one of the levers, not the default.

  1. 1

    Diagnose first: identify whether the bottleneck is CPU, memory, disk, network, or coordinator.

  2. 2

    CPU-bound: reduce ef, reduce candidates, add cores, or shard for parallelism.

  3. 3

    Memory-bound: add RAM, quantize, reduce the working set, or move data on-disk.

  4. 4

    I/O-bound: use NVMe, quantize, use inline storage, or add RAM for the page cache.

  5. 5

    Network/coordinator-bound: reduce shard count or use custom sharding to avoid fan-out.

  6. 6

    Optimizer contention: tune the optimizer thresholds or schedule it off-peak.

  7. 7

    Vertical ceiling: the largest machine may not be enough; cost grows super-linearly.

  8. 8

    Sharding: adding RAM to one node does not help if the query fans out to many nodes.

The trade-off is between the simplicity of vertical scaling and the flexibility of diagnosing and addressing the specific bottleneck. Vertical scaling is fast and simple but has a ceiling and a cost. Diagnosis takes time but leads to the right fix. The common mistakes are: (1) adding RAM without measuring the bottleneck; (2) assuming the bottleneck is memory because the collection is large; (3) ignoring the cost of the largest instances, which can be several times the cost per unit of a smaller instance; (4) not considering that the bottleneck may be a single shard or the coordinator; (5) treating 'add more RAM' as a complete answer rather than one of several levers. Version note: the metrics available to diagnose the bottleneck and the behavior of the optimizer have changed across Qdrant releases. Use the metrics available on your version and correlate them with client-side latency rather than relying on a fixed recipe.

javascript

Version-dependent: the metrics exposed by Qdrant and the behavior of the optimizer have changed across releases. Use the metrics available on your version and correlate them with client-side latency.

Difficulty: 7/10
Topics: Performance Tuning, Diagnostics, Capacity Planning

Scenario Questions

0-2 years experience
  1. 1

    Your Qdrant deployment is slow and a teammate says to add RAM. Explain what you would check first.

  2. 2

    You add RAM to a node and latency does not improve. Explain the likely reasons.

2-5 years experience
  1. 1

    You diagnose a CPU-bound workload and a teammate wants to add RAM. Explain why RAM will not help and what you would do instead.

  2. 2

    You have a memory-bound workload but the largest machine is not big enough. Describe the alternatives.

5-8 years experience
  1. 1

    Design a diagnostic procedure that identifies the bottleneck in a Qdrant deployment in under an hour, and describe the levers for each bottleneck type.

  2. 2

    You need to reduce cost without regressing latency. Describe how you would identify whether the deployment is over-provisioned or under-provisioned.

8+ years experience
  1. 1

    Derive a model for the cost of a Qdrant deployment as a function of the workload and the bottleneck, and explain how you would minimize the cost for a given SLO.

  2. 2

    You are designing a system that must scale from 10M to 10B vectors. Describe the scaling roadmap and the points at which the bottleneck changes.

Follow-up Questions

  • ❓How would you distinguish a CPU-bound from a memory-bound latency problem in a Qdrant deployment, using only metrics?
  • ❓If the collection is sharded across multiple nodes, how would you decide whether to add RAM to each node or to add more nodes?