NOTE
Designing a Service Registry
Service membership registration, discovery, leases/health, staleness, replication, client caches, and failure handling.
This is a historical learning note and may contain outdated or incomplete understanding.
A service registry maps a logical service to currently known instances and metadata. Instances may register explicitly or be discovered by an orchestrator/control plane; liveness uses leases/heartbeats/health signals depending on the design.
Discovery data is inevitably stale during propagation/failures. Clients still need connect timeouts, endpoint health/outlier logic, retries only where safe, and cache/fallback behavior when the registry is unavailable.
Design consistency/availability, update fan-out, multi-region semantics, access control, and operational recovery before choosing a specific implementation.