Explain the lifecycle of a search request in a distributed Milvus cluster?

A single search call from a client fans out across multiple components and, typically, multiple Query Nodes in parallel before being merged back into one final ranked result list.

Because a collection's segments are typically spread across multiple Query Nodes, the Proxy fans the same search request out to every Query Node holding a relevant segment, each of which independently computes its own local top-K results against just its assigned data. The Proxy then merges those partial result sets, since the globally correct top-K answer requires comparing across all of them, not just trusting any single node's local ranking, and returns the final merged, correctly-ranked list back to the client.

This fan-out-and-merge pattern is what lets search latency stay low even as a collection's total data volume grows into the billions of vectors: the actual per-node search workload for any given query stays roughly proportional to that node's share of the data, not the collection's total size, as long as segments are reasonably balanced across the Query Node fleet.