mTLS, Traffic Management, and Resilience¶
Once every request flows through a sidecar, the mesh can apply the same three categories of behavior to every service, consistently, without any application code caring.
TL;DR — in 30 seconds:
- mTLS (mutual TLS) — the mesh encrypts and authenticates traffic between sidecars automatically; both sides prove their identity with certificates the control plane issues and rotates, not just the server.
- Traffic management — the mesh can split traffic by rule: send 95% of requests to the stable version and 5% to a canary, or route by header, with no application-level load-balancer config.
- Resilience — retries, timeouts, and circuit breaking (stop sending requests to a failing instance) are configured once, at the mesh layer, instead of hand-rolled differently in every service.
1. mTLS: encryption and identity, for free¶
flowchart LR
A["Sidecar A<br/>cert: svc-a"] -->|"mTLS handshake<br/>both sides verify identity"| B["Sidecar B<br/>cert: svc-b"]
B -->|"encrypted traffic"| A
CP["Control plane"] -.->|"issues + rotates certs"| A
CP -.->|"issues + rotates certs"| B- Mutual means both ends authenticate — not just the client trusting the server (ordinary TLS), but the server also verifying the client's identity. Two compromised-looking pods can't just talk to each other unverified.
- The control plane acts as a certificate authority: it issues a certificate per service identity and rotates them automatically — no team manually manages TLS certs per service.
2. Traffic management: splitting and routing by rule¶
| Task | What the mesh does |
|---|---|
| Canary release | Route a small % of traffic to a new version; the rest keeps hitting the stable version |
| A/B or header-based routing | Route by request header/cookie to a specific version, no app-level logic |
| Blue/green cutover | Shift 100% of traffic from one version to another with a config change, not a redeploy |
This is declared as routing rules in the control plane (e.g. Istio's VirtualService /
DestinationRule) — the application never sees or implements the split.
3. Resilience: retries, timeouts, circuit breaking¶
| Task | What the mesh does |
|---|---|
| A downstream call fails transiently | the sidecar retries automatically, per policy, without app code |
| A downstream call hangs | the sidecar enforces a timeout and fails fast |
| A downstream instance is unhealthy | the sidecar's circuit breaker stops sending it traffic until it recovers |
- Why this matters: without a mesh, every service reimplements retry/timeout logic — inconsistently, often with none at all. The mesh makes it a uniform, centrally-tunable policy.
Common gotchas
- Assuming mTLS means the application is now "secure." Fix: mTLS secures service-to-service transport and identity — it says nothing about authorization logic, input validation, or app-level vulnerabilities.
- Stacking mesh-level retries on top of application-level retries. Fix: retries at both layers can multiply load during an incident (a retry storm) — pick one layer to own retries for a given call path.
- Treating traffic splitting as free. Fix: it still needs the new version to be running and healthy; the mesh routes traffic, it doesn't deploy or health-check application logic for you.
Check yourself — two services in the mesh both have their own internal retry logic, and the mesh is also configured to retry failed calls between them. A downstream dependency starts failing. What's the risk?
A retry storm — each failed call gets retried at both the application layer and the mesh layer, multiplying the load hitting the already-struggling dependency. The fix is deciding one layer owns retries for that call path, not stacking both.
Done when: you can explain what mTLS adds beyond ordinary TLS, describe one traffic-management use case (canary), and name the retry-storm risk of stacking retries at two layers.