Server-Side Discovery

The Mechanics

 caller knows ONE stable address; a MIDDLE layer resolves:

 [caller]──►[LB/router: orders.example]──resolve──►[instance]
             ▲ registry-backed, health-checked

 implementations across the spectrum:
 - CLOUD LBs with target-groups (aws/gcp native)
 - KUBERNETES Service: stable VIP → kube-proxy → pods
 - INTERNAL L7 routers: nginx/envoy tiers per service
 - SERVICE-MESH sidecars: proxy co-located per pod
   (discovery logic server-side but PER-NODE local)

 client code: plain HTTP to a DNS name. zero discovery
 libraries. that simplicity is the whole pitch.

Why Choose It

 □ CLIENTS STAY TRIVIAL: any language, any framework,
   even curl — no discovery library matrix to maintain
 □ POLICY CENTRALIZED: balancing/retry/timeout rules change
   in ONE place; instant fleet-wide effect
 □ PLATFORM ENFORCEMENT: security, mTLS, telemetry injected
   below app awareness — governance without code reviews
 □ REGISTRY ABSTRACTION: swap consul→cloud-native behind it;
   clients never notice

The Costs

 - EXTRA HOP per call: latency (~ms locally) + component to run
 - LB TIER = critical path: its failure outages everything
   behind it (mitigate: redundant, boring, battle-tested)
 - COARSE RETRY AWARENESS: generic LB can't retry as smartly
   as a caller knowing request semantics (idempotency!)
 - HOP-BY-HOP OBSERVABILITY needed: tracing must stitch
   through the proxy layer (standard now, still work)

The Sidecar Evolution

 server-side discovery's modern form: EVERY POD gets
 a local proxy (sidecar):

 [app]──localhost──►[sidecar: envoy]──►[registry/xDS]──►[peer]

 properties:
 + app keeps talking to localhost (zero-hop feel)
 + policy centralized via xDS control plane ✓
 + per-language complexity eliminated (the client-side cost)
 − operational weight: proxies everywhere to upgrade/monitor
 = this IS the service mesh (own lesson) — discovery became
   one facet of general traffic management.

Approach	Best when
Cloud LB / k8s Service	default choice — start here
Per-service router tier	L7 routing sophistication needed
Mesh sidecars	large polyglot estates, mTLS mandates

Interview Framing

“Polyglot microservices across 6 teams — discovery approach?” scored shape: server-side mechanics drawn, client-simplicity advantage emphasized FOR THIS scenario (polyglot!), hop/critical-path costs acknowledged honestly, k8s-Service-as-default named, sidecar evolution mentioned as the scaling path. Choosing by TEAM CONSTRAINTS rather than pattern loyalty is the graded skill here.