A sidecar is a process that runs alongside each service instance and handles cross-cutting concerns such as mutual TLS, retries, timeouts and telemetry. The application stays unaware, and a control plane configures the sidecars consistently across the fleet.
Before you start
You should understand service-to-service calls and basic networking. This article covers the sidecar pattern and service mesh; it is conceptual.
Step-by-step walkthrough
Step 1: Co-locate the proxy with each instance
Every service instance gets a proxy that intercepts inbound and outbound traffic. Because the sidecar is on the same host, it sees the traffic without the application changing, and language teams get the same behavior regardless of their stack.
Step 2: Configure centrally
A control plane pushes policy — mTLS, retry counts, timeouts, circuit breaking — to all sidecars, so a change applies fleet-wide instead of per service. This gives consistent, auditable behavior and removes duplicated networking code from each service.
Step 3: Watch for surprising retries and overhead
Automatic retries at the mesh layer can multiply a request across the fleet and duplicate non-idempotent writes, and per-instance sidecars add memory and latency. Make retry policy explicit, keep writes idempotent, and budget for the sidecar’s resources.
Worked scenario
The mesh applies mTLS and a timeout without app changes.
app -> (outbound) sidecar --mTLS--> sidecar (inbound) -> app
policy: timeout 2s, retries 2, circuit breaker on 5xxWalk through the example
The application makes a normal call; the outbound sidecar encrypts it and applies the timeout and retry policy, and the receiving sidecar verifies the certificate before forwarding. The application contains no TLS or retry code, yet every hop is encrypted and governed. This is the consistency the mesh provides.
Common mistake
Enabling mesh-level retries without idempotency, so a retried POST creates duplicates. Another is ignoring sidecar resource cost, which can be significant per instance at scale.
Verify the behavior
Confirm mTLS is active between instances by checking certificates in the mesh. Fail a dependency and observe the configured timeout and retry behavior. Send a non-idempotent request through a retrying policy and confirm whether duplicates occur, then fix with an idempotency key.
Interview exercise
Why can a mesh’s automatic retries be dangerous?
Answer and reasoning
Retries at the infrastructure layer apply to every call, including non-idempotent writes, so a transient error can result in the same operation running twice. They also multiply traffic during an outage, which can worsen it. The fix is to keep writes idempotent and to set retry policy deliberately rather than by default.
Continue learning
Compare resilience patterns in Retry budgets and Circuit breakers. Read the Istio sidecar documentation and try the Microservices interview questions.