Sidecar Pattern and Service Mesh (Istio)

The sidecar pattern deploys a proxy — typically Envoy — alongside each service container.

• All network traffic passes through the proxy transparently, so cross-cutting concerns like mTLS, circuit breaking, retries, and distributed tracing are handled without touching application code.
• The application makes a plain HTTP call; the sidecar handles the rest.

How a service mesh works:

• A service mesh is what emerges when you deploy sidecars to every service and manage them centrally; Istio has two planes — the data plane is the Envoy fleet handling traffic, and the control plane (Istiod) pushes configuration and certificates
• One YAML change — mtls.mode: STRICT — encrypts every service-to-service call without any code changes; per-instance circuit breaking via outlierDetection ejects unhealthy pods instead of blocking all traffic
• If Istiod goes down, existing config keeps working but updates stall — the data plane is resilient to control plane failures

The real cost:

• Each sidecar adds 1–5ms latency per hop and 50–100MB memory; at 200 pods, sidecars alone consume 10–20GB and you need a team that can operate the mesh
• Debug sidecar injection, handle certificate rotation, manage control plane availability — this is non-trivial operational overhead for teams without mesh experience

When the mesh pays off:

• Polyglot fleets where library-based solutions would require separate implementations per language
• Compliance-driven mTLS requirements where the alternative is per-service certificate management
• Advanced traffic management like canary routing, traffic mirroring, or fault injection testing

I recommend library-first (Resilience4j + Micrometer + Spring Security) for fewer than 20 services in a single language; the mesh becomes worth it at scale with polyglot or compliance requirements.