Envoy's xDS APIs are split into LDS, RDS, CDS and EDS (plus SDS). What does each one deliver, and how do they depend on one another?

## Four resources, one reference chain Envoy's configuration is a graph, and xDS splits that graph along its natural seams. Each discovery service carries exactly one node type, and the split is not arbitrary: it follows how often each part changes. **LDS — listeners.** A `Listener` is an address Envoy binds plus the filter chains that handle what arrives there. For HTTP that chain contains the `http_connection_manager` (HCM) network filter, which itself holds a chain of HTTP filters and a routing decision. Listeners change rarely — a new port is a deliberate act. **RDS — route configurations.** Inside the HCM you either write `route_config` inline or write: ```yaml rds: route_config_name: local_route config_source: { ads: {} } ``` That name is a pointer. RDS then delivers a `RouteConfiguration` containing `virtual_hosts`, each with `domains` and `routes`, and each route action naming a cluster. Routes change every time someone shifts traffic, so they get their own subscription, and a route push does not disturb the listener or its open connections. **CDS — clusters.** A `Cluster` is the definition of an upstream: its name, discovery type, load-balancing policy, connect timeout, health checking, circuit breakers, upstream TLS. It is the *shape* of a destination, not its membership. **EDS — endpoints.** When a cluster sets `type: EDS`, its membership arrives separately as a `ClusterLoadAssignment` keyed by the cluster's EDS service name. This is the highest-churn resource in the system: instances restart, autoscaling adds capacity, a health check ejects one. Splitting it from CDS means an endpoint change costs one small EDS message and touches nothing else in the config. **SDS — secrets.** TLS certificates, private keys and validation contexts, referenced by name from a listener's or cluster's TLS context. Its real value is operational: certificates can be rotated, and short-lived ones issued, without the private key ever being written to the proxy's filesystem or embedded in a pushed cluster definition. ## Why the order matters Because references point downward — listener → route config → cluster → endpoints — an update that adds the referencing object before the referenced one leaves a dangling pointer for as long as the gap lasts. A route naming a cluster Envoy has never heard of produces a 503 for every request that matches it; a listener whose route configuration has not arrived cannot route anything. Envoy's documented sequence for a client applying updates is therefore **CDS, EDS, LDS, RDS** — sometimes called *make before break*: create the thing that will be referenced, then create the reference. Deletion runs the other way: remove the reference first, then the resource, so nothing points at a resource in the middle of being torn down. This ordering is only enforceable when all four types travel on one stream, which is exactly the argument for the aggregated stream. With independent subscriptions the resource types are separate connections with no relative ordering guarantee at all. ## Not every resource has to be dynamic The types are independent, and mixing is normal. A common sidecar layout is dynamic everything. A common edge-proxy layout is a static listener with a static filter chain (nobody is redefining the ports on your ingress), CDS+EDS for the upstreams, and RDS for the routes because that is where traffic-shifting work happens. A cluster can also skip EDS entirely and use `STRICT_DNS` or `LOGICAL_DNS`, in which case Envoy resolves the name itself and no EDS subscription exists for it — worth knowing because "endpoints are stale" has a completely different investigation depending on which one you chose. ## Naming and subscriptions LDS and CDS are *wildcard* subscriptions: Envoy asks for everything it should have, and the management server decides what that is from the `node` identity presented on connect. RDS, EDS and SDS are subscriptions **by name** — Envoy asks for exactly the route configurations, EDS service names and secrets that the resources it already holds referred to. This is why the flow is naturally staged: Envoy cannot ask for an endpoint set until a cluster has told it that set exists. It also explains a common confusion in debugging. If a route configuration never arrives, the first question is not "is the control plane broken" but "did any listener actually name this route config?" — because if nothing named it, Envoy never subscribed to it. ## Beyond the four The family has more members, worth naming but not memorising: VHDS for delivering individual virtual hosts on demand, SRDS for scoped route configurations, RTDS for runtime layers, and ECDS for extension configuration. They exist for scale problems — a proxy that would otherwise hold a route table with tens of thousands of virtual hosts. Knowing they exist is enough; knowing LDS/RDS/CDS/EDS/SDS cold is not optional.