Challenge 2: Client-Side or Proxy LB? — Possible Solution
====================================================================

SMALL TEAM, THREE SERVICES, SIMPLE ROUTING, WANTS TO AVOID EXTRA
INFRASTRUCTURE — CLIENT-SIDE LOAD BALANCING. With only three services
and simple needs, running a dedicated proxy/service-mesh layer (Envoy,
Istio) would add real operational overhead — more infrastructure to
deploy, monitor, and maintain — for a problem that's small enough for
a simple resolver and round-robin client-side policy to handle
directly. The team's own stated preference (avoid extra infrastructure)
lines up exactly with client-side LB's trade-off: slightly more logic
embedded in each client, but no additional infrastructure pieces to
run.

LARGE ORGANIZATION, 200 MICROSERVICES, WANTS CENTRALIZED TRAFFIC
POLICY AND OBSERVABILITY — PROXY/SERVICE MESH LOAD BALANCING. At this
scale, embedding and consistently maintaining balancing logic across
200 different services' worth of client code becomes its own
significant burden — any change to routing policy, retry behavior, or
observability would need to be rolled out to every single service
independently. A proxy-based approach (a service mesh like Istio with
Envoy) centralizes all of that: policy changes happen in one place,
observability is consistent across the whole fleet, and individual
services don't need to embed or maintain any of that logic themselves.
This matches the organization's explicitly stated need for
CENTRALIZED policy and observability directly.