What are the main components of Milvus's architecture?

A distributed Milvus deployment follows a disaggregated, cloud-native design organized into four broad layers, each independently scalable.

1. Access layer (Proxy) - stateless entry point that receives client requests, validates them, and routes them to the right internal services.
2. Coordinator services - RootCoord (metadata/DDL), DataCoord (segment and channel management), QueryCoord (search cluster orchestration), and IndexCoord (index build scheduling), which manage cluster state without processing data directly.
3. Worker nodes - QueryNode (executes search/query), DataNode (ingests and flushes data), and IndexNode (builds indexes), which do the actual data processing.
4. Storage layer - etcd for metadata, a message queue (Pulsar, Kafka, or RocksMQ) for the write-ahead log, and object storage (S3, MinIO, or similar) for the actual vector and index data.

This separation means each layer can scale independently based on its own bottleneck: adding QueryNodes for read-heavy workloads, or DataNodes for write-heavy ingestion, without needing to scale the whole system uniformly, which is central to how Milvus handles workloads ranging from a single laptop up to billions of vectors across a large cluster.