Service Mesh and Service Discovery Architecture
In a microservice system, services must find each other (discovery) and talk reliably (retries, timeouts, mTLS, load balancing, telemetry). A service mesh moves that cross-cutting networking logic out of every application and into a dedicated infrastructure layer of proxies, so services stay business logic only.
Service discovery solves "where is service B right now?" in a world of ephemeral, autoscaling instances: a registry tracks healthy instances (registered on startup, deregistered on failure), and callers resolve names to addresses via the registry — either client-side (caller picks an instance) or server-side (a load balancer/DNS resolves it). Source: compiled from service-discovery literature
Mesh structure: data plane + control plane
- Data plane — a sidecar proxy (e.g. Envoy) deployed beside each service instance; all service-to-service traffic flows through it. The proxy does discovery, load balancing, retries, timeouts, circuit breaking, mTLS, and metrics.
- Control plane — configures and coordinates the proxies (policy, certificates, routing rules, telemetry aggregation). Operators set intent centrally; the control plane pushes it to every sidecar.
What the mesh provides
- Traffic management — load balancing, canary/blue-green splits, request routing.
- Resilience — retries, timeouts, circuit breaking, outlier ejection — uniformly, without app code.
- Security — automatic mutual TLS and identity-based authz between services (zero-trust networking).
- Observability — consistent golden-signal metrics, traces, and logs from every hop, for free (see Observability Architecture).
Mesh vs gateway
A gateway handles north-south traffic (external clients → cluster). A mesh handles east-west traffic (service ↔ service inside the cluster). They are complementary layers, not alternatives.
Design implications
- Cost is real. A sidecar per instance adds latency (extra hops), memory, and operational complexity; small systems do not need a mesh — libraries or a gateway suffice.
- Uniformity is the payoff. Policy (mTLS everywhere, retry budgets) is enforced once in the platform, not re-implemented per service/language.
- The control plane is critical infra. Its outage degrades config propagation; the data plane should fail static (keep last config).
Architecture Position
| Axis | Value |
|---|---|
| Family | Distributed systems primitives |
| Boundary owned | Service discovery and service-to-service reliability, policy, and observability. |
| Read with | API Gateway Architecture, Observability Architecture, Resilience Patterns (Circuit Breaker, Bulkhead, Retry) |
| Use this page when | designing internal service communication |
Timeline
-
2026-07-01 | Architecture category refresh added this page to the Distributed systems primitives family, linked it to Architecture System Map, and kept it standalone because it owns this boundary: Service discovery and service-to-service reliability, policy, and observability. Source: User request, 2026-07-01
-
2026-06-02 | Page created. Captured service discovery + registry, client/server-side resolution, the data-plane/control-plane sidecar model, what a mesh provides (traffic/resilience/security/observability), north-south gateway vs east-west mesh, and the cost-vs-uniformity tradeoff. Source: compiled from service-mesh and service-discovery literature