Service Discovery

The Problem: Moving Targets

 cloud reality: instances appear/vanish/scale/die continuously.

 [orders-v3] [orders-v3] [orders-v2] ... which IPs are LIVE?
 autoscaler added 4 at 14:02, killed 2 at 14:07...

 hardcoding IPs/hosts = guaranteed breakage.
 SERVICE DISCOVERY: a live map of where-capable-instances-are.

   register:  instance announces itself (or platform does)
   query:     callers ask "healthy orders instances?"
   health:    dead instances drop OFF the map automatically

The Registry Pattern

 components:

 SERVICE REGISTRY (consul, etcd, eureka, k8s API):
   key: service-name → value: instance addresses + metadata
   consistency via consensus; health-checked

 REGISTRATION:
   SELF-registration: instance registers on boot ✓ common
   THIRD-PARTY: deploy platform registers (k8s model —
                the platform KNOWS pod state already)

 HEALTH CHECKS:
   heartbeat/TTL:      instance must keep renewing
   ACTIVE checks:      registry probes /health endpoints
   failed → DEREGISTER → traffic stops flowing to corpses

 RESOLUTION:
   CLIENT-side: caller fetches list, load-balances locally,
                retries smartly (more control, client complexity)
   SERVER-side: call a LOCAL LB/proxy that resolves
                (simpler clients; extra hop)

Kubernetes Made This Boring (mostly)

 k8s bundles discovery into the platform:

 Service object = stable virtual IP/DNS name
   orders.default.svc.cluster.local
 → kube-proxy/routes to current healthy pod set
 → endpoints tracked automatically from liveness/readiness

 practical consequence: most teams get discovery FREE now.
 custom registries justified for: multi-cluster federation,
 legacy/non-k8s estates, advanced traffic steering needs.

 know the CONCEPTS anyway — interviews predate k8s monoculture
 and hybrids persist everywhere.

Design Considerations

Concern	Approach
Stale routes	short TTLs/caching + client retry on failure
Registry outage	clients CACHE last-known-good; degrade gracefully
Zone awareness	prefer same-AZ instances (latency + cost)
Version skew	metadata tags; traffic splitting by version
Startup storms	backoff registration until readiness proven

 the registry-outage case deserves respect:
 registry down ≠ everything stops IF clients cache.
 design for "discovery frozen but functional" degradation —
 it converts an outage into a non-event.

Interview Framing

“200 service instances scaling dynamically — how do calls route?” scored shape: registry pattern with register/query/health triad drawn, client-vs-server resolution tradeoff stated, staleness handling named (TTL+retry), k8s-native answer acknowledged as modern default, registry-degradation note. Discovery questions check whether you think in DYNAMIC systems or static diagrams — emphasize the churn-handling.