Interview › Istio & Service Mesh
What is the typical latency and resource overhead of the sidecar, and how do you minimise it?
Istio & Service Mesh · Intermediate level
Answer
The sidecar adds CPU, memory, startup, and latency overhead because every request passes through an additional proxy. The exact overhead depends on traffic volume, protocol, telemetry, TLS, filters, and resource limits, so I measure it in my own environment rather than quoting a single universal number.
Technical explanation
Overhead is reduced by right-sizing proxy CPU/memory, limiting high-cardinality telemetry, avoiding unnecessary Envoy filters, and applying mesh only where value justifies cost.
High-QPS gateways and chatty services need dedicated capacity tests.
Ambient mode can reduce per-pod sidecar overhead, but L7 waypoint usage still needs capacity planning.
Hands-on example
Measurement plan:
Run the same load test without mesh and with mesh.
$ fortio load -qps 200 -t 10m http://checkout/
Compare p50/p95/p99 latency, CPU, memory, connection count, retries, and error rate.
Then tune proxy resources and telemetry before declaring the mesh too expensive.
Check how well your resume matches the role with our free resume checker— match score, ATS check, and the skills you're missing.
More Istio & Service Mesh interview questions
- What is Istio, and what are the core capabilities it provides?
- What is the difference between the Istio control plane and data plane?
- What is istiod, and what does it do?
- What is Envoy, and what role does it play in Istio?
- What is the sidecar pattern, and how does Istio inject the proxy?
- How does automatic sidecar injection work (namespace label, webhook)?
- What is the Istio ambient (sidecarless) mode, and how does it differ from sidecar mode?
- What is the difference between ztunnel and a waypoint proxy in ambient mode?