Health Check & Service Discovery  ·  View 14 of 21  ·  Runtime

Registration To Eligible

Four runtimes with four different amounts of evidence, and one row that is identical for all of them.

Editable source SVG draw.io All views
Appears Identified Probed Eligible At full weight EKS pod EndpointSlice watch IRSA identity Readiness + liveness 20 s to eligible 60 s slow start ECS task Task state change Task role identity Container health + self 20 s to eligible 60 s slow start EC2 fleet instance ASG lifecycle hook Instance profile Agent self-report Lease renewal required 60 s slow start Third-party endpoint Declared by owner Owner's identity No signal available Eligible, health unknown Passive outcomes only What the caller sees Nothing yet Nothing yet Nothing yet Endpoint, weight 0.1 Endpoint, full weight Registration To Eligible — Four Runtimes, One Surface The caller's row is identical for all four. Capability is declared per service, so the third-party row is honest rather than hidden. v 1.0 · owner Reliability Architecture

Decisions

  • The caller's row is the same for every runtime: an endpoint at weight 0.1, then an endpoint at full weight.
  • Capability is declared per service, so the third-party row reads 'health unknown' rather than pretending to a readiness signal (ADR-16).
  • A fleet instance renews a lease; an orchestrated one does not need to, because its orchestrator is already watched.

Assumptions

  • 20 s from first readiness pass to eligible; 60 s ramp to full weight; 30 s lease expiry for ungraceful exits.

Open

  • Whether callers can be trusted to handle a 'health unknown, route anyway' endpoint correctly — see Question 7.
◀  Critical Flow — A Replica Fails All views Eligibility Decision Path  ▶
Solution Architecture v1.0 · Amazon Web Services with an open-source Envoy/xDS data plane · Reliability Architecture · 2026-10 · 21 views · 16 architecture decision records14-registration-to-eligible