Service Discovery

The pattern: how do clients find the current healthy IP+port for a logical service? Static config (hosts file) doesn’t scale. DNS scales but caches. Health-aware registries (Consul, etcd, K8s endpoints) self-update. The mesh layer often hides this entirely — http://triage just works.

The trade-off: freshness vs. cache consistency. TTLs let DNS scale; they also delay propagation when a backend dies. K8s Services + endpoints offer near-instant updates inside the cluster (kube-proxy + CoreDNS); cross-cluster needs federation. Service mesh (with sidecars or ambient) often takes over discovery entirely, decoupling client from the registry.

Deepens in Year 1 Phase 7: Kubernetes + GitOps — kubectl get endpoints, the CoreDNS resolution path, kube-proxy iptables. DNS fundamentals come from Year 1 Phase 2: Networking, and discovery-path telemetry (resolution latency, NXDOMAIN spikes, endpoint churn) lands in Year 3 Phase 14: Observability + eBPF.

Related patterns

• load-balancing — discovery returns the candidate set; LB picks one.
• routing-and-addressing — discovery resolves names into addresses to route on.
• service-mesh — often takes over discovery entirely from the application.
• eventual-consistency — registry updates and DNS TTLs are an eventual-consistency story.
• zero-trust-networking — discovery has to deliver identity, not just an IP.