Service Mesh

You have 50 microservices in production. Every service-to-service call needs: TLS encryption, mTLS auth, retries, timeouts, circuit breaking, observability, traffic routing. Implementing all of that in every service, in every language is impossible to maintain. Half your services do retries differently; some forgot mTLS; nobody can tell where the latency cliff is.

A service mesh moves all of that into a sidecar proxy that runs alongside each service. Application code becomes simple HTTP/gRPC calls; the sidecar handles everything operational. One config file in one place changes behavior everywhere.

Each pod runs your service container plus a sidecar proxy (Envoy is the dominant choice). All traffic in/out of the pod goes through the sidecar. The sidecar handles: TLS termination, mTLS to peers, retries, timeouts, circuit breaking, traffic shaping, request logging, distributed tracing.

A central control plane (Istiod, Linkerd's control plane, Consul) pushes configuration to all sidecars: who can talk to whom, what timeouts apply where, how to route traffic. Sidecars pull this via xDS from Envoy.

• Zero-trust networking — mTLS for every service-to-service call, automatic certificate rotation. App code talks plaintext HTTP locally; the sidecar wraps it.
• Traffic shaping — "send 5% of v2 traffic to the canary." Configured centrally, applied at the data plane, no code changes.
• Resilience policies — retries, timeouts, circuit breakers, rate limits. One YAML changes them everywhere.
• Observability — uniform metrics (success rate, P99, RPS) per service edge, automatic distributed tracing, no app-side instrumentation.
• Authorization — "service A can call service B's /orders endpoint but not /admin." Enforced at the sidecar, not the app.

Service mesh isn't free. Real costs:

• Latency tax — every request goes through 2 extra proxy hops (out via your sidecar, in via the peer's). Adds 1-3ms per call.
• Memory tax — each pod runs an Envoy (~50-100 MB). At 1000 pods = 100 GB just for sidecars.
• Operational complexity — the mesh itself is a distributed system. Istio has reputation for being hard to debug. A misconfigured mesh policy can take down inter-service communication everywhere at once.
• Yet another layer — when something is slow, the failure could be in app, sidecar, control plane, or peer's sidecar. Diagnosis surface area grows.

The sidecar pattern is dominant but not universal. Recent alternatives:

Linkerd's micro-proxy — a Rust-based proxy ~10× lighter than Envoy. Same model, fraction of the resource cost.

Istio Ambient Mesh — the new architecture (2023+). Replaces per-pod sidecars with shared per-node ztunnels for L4 (mTLS) + optional waypoint proxies for L7. Cuts memory cost dramatically; trade-off is more complex routing.

eBPF-based meshes (Cilium Service Mesh) — implement mesh capabilities in the kernel via eBPF. No userland proxies in the data path. Lowest latency overhead. Newer; less mature than Istio/Linkerd.

The trajectory: the original "sidecar everywhere" pattern is being replaced by lighter approaches. By 2027 most production meshes will likely be ambient-style or eBPF-based. The capabilities stay the same; the overhead shrinks.

News feed's microservices run inside Istio for mTLS + uniform observability. Uber's massive microservice fleet uses Envoy-based mesh internally. E-commerce uses mesh for traffic shaping during checkout-flow experiments.