GCP Service Directory Centralizes Service Registration. Registration Is Not Governance.

Vendor and product reality

Service Directory is part of Google Cloud's networking portfolio and is positioned alongside Cloud DNS, Traffic Director, and the broader Anthos service-mesh stack. The product surface is small and intentional. The data model has three levels: a project-scoped namespace, a service inside a namespace, and one or more endpoints inside a service, where each endpoint carries an address, port, and a map of string annotations. The control surface is the Service Directory API for create, update, delete, and list operations and the resolve API for clients that want a single round trip to fetch all endpoints for a service. The DNS integration synthesizes A and SRV records from registered endpoints inside private DNS zones bound to the namespace, which lets unmodified DNS clients consume the registry transparently.

Customers adopt Service Directory in three common patterns. As a hybrid registry, where workloads in GKE, on-prem VMs, and other clouds all register to one directory and discover one another by name. As a service-mesh metadata source, where Traffic Director or an Envoy-based mesh consumes Service Directory entries to populate its endpoint discovery service. As a multi-region failover registry, where regional services register with health-derived annotations that clients consult to choose endpoints. In all three patterns the registry is operated as a Google-managed control plane: registration semantics, consistency model, and durability are properties of the GCP service, and customers consume them through IAM-gated APIs.

Architectural gap

The structural property worth naming is that registration authority sits with GCP and is decoupled from the service identity it admits. A registration succeeds if the calling principal has servicedirectory.services.update on the namespace and the request is well-formed. There is no structural validation that the registration is consistent with the existing namespace beyond uniqueness on the resource name, no trust-weighted approval pathway among the parties that depend on the namespace, and no lineage record that travels with the service identity describing how it was admitted, by whom, against what rule version, and with what subsequent mutations. The directory is authoritative because Google operates it, not because the namespace governs itself.

Two operational consequences follow. First, the rules that decide whether a service identity is valid in a downstream context do not ship with the identity. A service mesh consuming Service Directory must apply its own policy to decide whether a registered endpoint is admissible into a routing table; a client doing DNS-based discovery has no governance metadata at all beyond the records it resolves. The annotations system is expressive but advisory: it is metadata the registrant chose to attach, not consensus-validated rules bound to the identity. Second, the namespace structure is static with respect to its workload. As topologies grow, regions split, ownership changes, or communication patterns shift, the registry's organizational hierarchy does not adapt. New services and endpoints are added; old ones are removed; the namespace and service tree remain whatever the customer initially configured. There is no mechanism for the namespace to split when a region becomes overloaded with registrations, to merge when services consolidate, or to reorganize when consumer-producer affinity changes.

IAM is sometimes mistaken for governance in this context, but it answers a different question. IAM decides who may write. Governance decides whether what is being written is admissible against the consensus rules of the scope it targets, and what lineage that admission produces. Service Directory has the former and not the latter.

What the adaptive-indexing primitive provides

Adaptive indexing inverts the locus of authority for the namespace. Each scope, corresponding roughly to what Service Directory calls a namespace or a service, is governed by a local anchor that holds the consensus-validated rule set for that scope. Mutations, whether registration of a new endpoint, modification of annotations, or structural reorganization of the scope itself, are validated against the rules held at the scope and produce lineage entries that travel with the resulting identity.

Three structural properties follow. First, the rules ship with the service identity. A downstream consumer, whether a service mesh, a sidecar proxy, or an unmodified DNS client backed by an adapter, can verify that an endpoint was admitted under a particular rule version and that subsequent mutations preserved lineage, without trusting a single managed control plane to remain authoritative on its behalf. Second, the namespace adapts structurally. A scope that exceeds its registration or query envelope can split into child scopes that inherit governance and diverge on parameters; a dormant scope can be merged; a scope whose criticality rises can have its consensus threshold raised without rewriting the registry's configuration globally. Third, governance is local to each scope. The nodes responsible for a segment hold its rule set and its lineage; they are not asking a global controller for permission, and they are not subject to a uniform IAM-style policy that does not distinguish between a debug-tier service and a payments-tier service.

The primitive does not replace service discovery. The wire-level lookup, DNS synthesis, and resolve API patterns that Service Directory implements are well-engineered solutions to the data-plane problem of finding endpoints. Adaptive indexing is the governance plane the registry currently lacks.

Composition pathway

A practical composition with Service Directory preserves the existing data plane and inserts the adaptive-indexing primitive at the boundary where namespace authority currently sits. Three insertion points are natural. At registration, an admission adapter in front of the Service Directory API can validate proposed mutations against the scope's consensus rules before forwarding the call, attaching governance metadata as annotations so that the registry record carries lineage references even though it remains a managed GCP resource. At resolution, a thin shim in the DNS or gRPC discovery path can verify that the resolved endpoint's annotations match the consuming scope's required rule version, and quarantine or downgrade endpoints that do not. At the structural layer, the scope graph held by the primitive can drive reorganization of the underlying Service Directory namespaces and services, splitting and merging the registry's organizational tree as the governed scopes evolve.

Downstream consumers benefit symmetrically. A service mesh consuming the registry can enforce admission against governance metadata it can verify, rather than against advisory annotations it must trust on faith. Multi-cloud and hybrid topologies that span beyond GCP can interoperate without requiring every participating environment to depend on the same managed control plane: the scope graph is the federation primitive, and Service Directory is one substrate among several.

Commercial and licensing posture

Service Directory is billed on a per-endpoint and per-API-call basis under standard GCP commercial terms, with regional and multi-regional pricing tiers and SLA-backed availability. The product is a managed service, so customers do not license a binary; they consume an API. Adaptive indexing is positioned as a complementary primitive that runs in the customer's own environment (on GKE, on Cloud Run, or on workloads outside GCP) and integrates with Service Directory through documented APIs and DNS interfaces, under licensing terms compatible with GCP's terms of service. The primitive does not require modification of Google's control plane and does not interfere with the SLA Google offers on the registry; it adds a structural governance layer above the registry that the registry itself does not provide, while leaving the data-plane economics of Service Directory unchanged.