Health Check & Service Discovery  ·  View 09 of 21  ·  Structure

Interface Catalogue

Four interfaces in, four out, and exactly one contract in each direction.

Editable source SVG draw.io All views
Inbound — what feeds it Orchestrator watch EKS, ECS, Auto Scaling Instance API register, health, drain Outcome channel reported by callers Policy API contracts, evacuation Health & Discovery Plane Regional control plane advisory Outbound — what it publishes xDS subscription primary surface DNS zone compatibility surface Resolution API tooling, target groups Signal + audit export 90-day, 5-year self only deltas Interface Catalogue — Three Ways In, Three Ways Out External / third party Interface / broker Application we own synchronous event / async Four interfaces in, four out, and one contract in each direction: identity-attributed input, versioned output. Target-group membership rides the resolution API; no surface here may be read synchronously on a request. v 1.0 · owner Reliability Architecture

The two contracts

  • Inbound: every input is attributed to a registered identity, and an instance may report only about itself.
  • Outbound: every view carries its version and its staleness, and no surface may be read synchronously on a request.
  • The resolution API is for tooling and target-group sync. A caller using it on the hot path has misunderstood the design.

Deliberate omissions

  • Edge labels were cut to the single constraint that matters on each side; each interface's `sub` names what it carries.
  • Health reporting rides the Instance API rather than getting a surface of its own — one identity, one lease, one contract.

Assumptions

  • 150,000 resolution API calls/second, of which ≥ 99% are expected to be served from client cache and never arrive.