Service Discovery

solution: | Patterns:

1. Client-Side Discovery

   • Client queries registry, load balances locally
   • Pros: no proxy hop, client controls LB policy
   • Cons: client logic per language, registry coupling
   • Examples: Netflix Eureka, Consul (client), etcd (client)

2. Server-Side Discovery (Proxy/Load Balancer)

   • Client → LB/Proxy → instances (LB queries registry)
   • Pros: client simple, central LB policy, TLS termination
   • Cons: extra hop, LB scaling, single point (mitigate: HA)
   • Examples: AWS ALB, NGINX + Consul Template, Envoy + SDS, Kubernetes Service

3. DNS-Based Discovery

   • Service → DNS record (A, SRV, TXT)
   • Client resolves DNS → IPs
   • Pros: universal, cached, no client library
   • Cons: TTL caching delays, limited metadata, no health checks in DNS
   • Examples: Kubernetes CoreDNS, Consul DNS, AWS Cloud Map

Registry Backends:

• Consul: full-featured, health checks, KV, multi-datacenter
• etcd: Kubernetes native, strong consistency, watch
• ZooKeeper: mature, heavy, Java-centric
• Eureka: Netflix, AP mode, self-preservation
• Cloud Provider: AWS Cloud Map, GCP Service Directory, Azure Service Fabric

Registration:

• Self-registration: instance registers itself (health endpoint)
• Third-party: orchestrator registers (Kubernetes, Nomad)
• Heartbeat: TTL-based, deregister on missed heartbeats

Health Checks:

• Liveness: process alive (k8s livenessProbe)
• Readiness: ready to serve traffic (k8s readinessProbe)
• Application: custom checks (DB, dependencies, disk)

Metadata: version, zone, tags, endpoints (gRPC, HTTP), capacity. whenToUse:

• "Dynamic environments (k8s, autoscaling, frequent deploys)"
• "Multiple services needing to find each other"
• "Cross-region, hybrid cloud" whenNotToUse:
• "Static infrastructure (few fixed IPs)"
• "Simple architectures (hardcoded OK)"
• "Team not ready for discovery infrastructure" pros:
• "Enables autoscaling, rolling deploys, failure recovery"
• "Decouples clients from instance IPs"
• "Supports blue-green, canary, multi-region" cons:
• "Infrastructure: registry cluster, health checks"
• "Complexity: registration, deregistration, health checks"
• "Stale data: cache TTL, eventual consistency"
• "Registry SPOF (mitigate: HA cluster)" costProfile: infra: "Low-Medium — registry cluster" operational: "Medium — health checks, registry ops" cognitive: "Low — standard patterns" operationalBurden: "medium" maturity: "established" tradeoffAxes:
• "client vs server vs DNS: control vs simplicity"
• "registry choice: features vs operational cost"
• "registration: self (autonomous) vs third-party (orchestrator)" failureModes:
• "Registry down: new instances invisible, existing cached"
• "Stale cache: client hits dead instance"
• "Split-brain: registry partition → inconsistent views"
• "Registration storm: mass startup → registry overload"
• "Health check flapping: instance flaps in/out" realWorldExamples:
• system: "Kubernetes Service Discovery" sourceUrl: "https://kubernetes.io/docs/concepts/services-networking/service/"
• system: "Consul" sourceUrl: "https://www.consul.io/docs/discovery"
• system: "Netflix Eureka" sourceUrl: "https://github.com/Netflix/eureka"
• system: "AWS Cloud Map" sourceUrl: "https://aws.amazon.com/cloud-map/"
• system: "etcd" sourceUrl: "https://etcd.io/docs/v3.5/learning/api/#service-discovery" alternatives: ["hardcoded-ips", "static-config", "load-balancer-only", "dns-only"] relatedPatterns: ["load-balancing", "kubernetes", "consul", "etcd", "health-checks", "circuit-breaker"] competencyDomains: ["distribution-communication", "reliability-ops", "deployment", "economics-evolution", "scaling"]