<arch.design/>
Principles/Service Mesh
InfrastructureInfrastructureadvanced2017istioenvoysidecarmtls

Service Mesh

Offload cross-cutting network concerns (mTLS, retries, circuit breaking, observability) to a dedicated infrastructure layer via sidecar proxies.

3/5
Operates at: Infrastructure level

Deployment platform — Kubernetes, Docker, cloud config

Interactive visualization

Live
FrontendServiceOrderServicePaymentServiceNo mTLSPlain HTTP betweenservices — unencrypted

Problems without a mesh

Service-to-service traffic is plain HTTP — readable on the network
Every service must implement retries, timeouts, circuit breakers itself
No uniform observability — each team instruments differently
No way to enforce which service can call which

How it works

A service mesh injects a sidecar proxy (typically Envoy) alongside each service container. All inbound and outbound network traffic passes through the sidecar, which enforces policies without any changes to application code.

The data plane (all sidecars) handles: mutual TLS (mTLS), retries, timeouts, circuit breaking, traffic shaping, and telemetry. The control plane (Istio, Linkerd, Consul Connect) distributes configuration to all sidecars.

This eliminates duplicated network logic from each service and enables zero-trust security by default.

Why it matters

In large microservices deployments, implementing mTLS, retries, and observability in each service is error-prone and inconsistent. Service mesh makes the network observable and secure by default.

When to use

  • Large microservices deployments with complex inter-service traffic
  • Zero-trust security requirements (mTLS between all services)
  • Fine-grained traffic control (canary releases, A/B testing at network layer)

When NOT to use

  • Small deployments — sidecar overhead is disproportionate
  • Monolithic or simple two-service architectures

Trade-offs

+

Network policies and mTLS without application code changes

Significant operational complexity and resource overhead per sidecar

+

Uniform observability across all services

Debugging involves two layers (app + sidecar)

In production

Google

Istio (co-created by Google) runs on GKE clusters across all product lines

Lyft

Created Envoy proxy, which powers most service meshes

Industry adoption

3/5Common in specific contexts — used when the problem fits.

Related principles