Estimate the latency and resource overhead a service mesh adds to your architecture.
Every hop through a sidecar proxy adds a small, roughly constant amount of latency for TLS, routing decisions and telemetry collection: latency_added_ms = proxy_hops × per_hop_ms. A typical service-to-service call in a mesh traverses two hops — the caller's outbound sidecar and the callee's inbound sidecar — and each active sidecar also consumes CPU proportional to the traffic it proxies, which should be budgeted alongside the application container's own resource requests.
overhead_percent = (latency_with_mesh - latency_without_mesh) / latency_without_mesh × 100
Most service mesh architectures (Istio, Linkerd) add 2 hops per service-to-service call — the client's outbound sidecar and the server's inbound sidecar — though calls through an ingress gateway or additional intermediate services add more.
For modern high-performance proxies like Envoy or Linkerd's Rust-based proxy under moderate load, 0.5-2ms per hop for p50 latency is typical; p99 tail latency can be considerably higher under resource contention or with expensive per-request policies (e.g. complex authorization checks).
The TLS handshake cost is amortized across a connection's lifetime via session reuse and connection pooling, so per-request overhead from mTLS is typically small once connections are warm — see the dedicated mTLS performance calculator for a detailed breakdown.
Multiply the per-sidecar CPU overhead percentage by your application containers' baseline CPU requests, then add that as extra CPU request/limit for each sidecar container — this mesh 'tax' should be included in overall cluster capacity planning.