Interview › Istio & Service Mesh
What are retries in Istio, and what are the risks of misconfiguring them?
Istio & Service Mesh · Basic level
Answer
Retries let Envoy automatically retry failed requests under configured conditions. They can improve resilience for transient failures, but misconfigured retries can amplify load, duplicate non-idempotent operations, and create retry storms during incidents.
Technical explanation
Retries are safer for idempotent GET or read operations than for payment, order creation, or side-effecting writes.
Retry attempts must be bounded by timeout budgets and downstream capacity.
Retry policies should specify retryOn conditions, attempts, perTryTimeout, and overall route timeout.
Hands-on example
Safe-ish retry example for a read API:
retries:
attempts: 2
perTryTimeout: 300ms
retryOn: gateway-error,connect-failure,refused-stream
timeout: 1s
Do not blindly apply this to POST /charge. For writes, prefer idempotency keys and explicit application-level retry design.
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?