Design the control plane that lets services in a large microservice fleet find one another and route only to healthy instances. Every service instance registers itself, sends periodic heartbeats, and is health-checked; callers resolve a logical service name to a current set of live endpoints and load-balance across them. The core tension is that membership is always slightly stale, and you must decide when a silent instance is "probably dead" without evicting a healthy one during a network blip.

Operating context. An internal platform runs roughly 20,000 instances across ~2,000 logical services in 3 regions. Instances churn constantly: deploys, autoscaling, and crashes cause about 500 register/deregister events per second at steady state, spiking to 5,000/sec during a rolling deploy. Every caller resolves endpoints very frequently — on the order of 150,000 lookups/sec fleet-wide, mostly served from a local cache. Heartbeats arrive at about 20,000/sec (one per instance every ~1s). A stale or wrong endpoint set sends live traffic to a dead box, so freshness and correctness both matter.

Out of scope. The L7 request proxy/data-plane internals, mTLS/certificate issuance, config distribution unrelated to membership, traffic-shaping policy (canary/retries/circuit-breaking logic itself), and the container scheduler. Assume separate teams own those; you consume their signals.

What to produce. A high-level architecture covering: the registry components and the register/heartbeat/deregister request paths; the health-check model (self-report vs. active probe, who probes, and the failure threshold that declares an instance down); how membership changes propagate to every caller and how fresh a resolve result is; the resolve path and client-side vs. server-side load-balancing trade-off; how stale/zombie entries are reaped without flapping; and the consistency-vs-availability posture during a network partition. Sketch the components and the flows between them; we probe specifics in checkpoints.