Every team writes the same retry logic. The same circuit breaker boilerplate. The same mTLS handshake setup. The platform team changes the retry policy and now has to update 30 services. There’s a better way.

The Sidecar Pattern#

A sidecar is a separate process running in the same pod as your service. It intercepts all network traffic in and out. Your service code is unchanged. The sidecar handles retries, timeouts, circuit breaking, load balancing, and observability. Your service just makes a plain HTTP call. The sidecar does the rest.

Cross-cutting networking concerns belong to infrastructure, not application code. A Java service and a Go service get the same retry behavior because the sidecar is the same regardless of what language sits next to it.

What a Service Mesh Adds#

A service mesh is a network of sidecars with a control plane. The sidecar (data plane) handles traffic. The control plane configures all sidecars centrally. “Increase the timeout for the payment service to 5 seconds” propagates to every sidecar that calls the payment service, without touching any application code.

Istio and Linkerd are the two main implementations. Envoy is the most common sidecar proxy underneath both.

graph TD A[Service A - your code] --> B[Sidecar Proxy - Envoy] B --> C[Service Mesh Control Plane] C --> D[Sidecar Proxy - Envoy] D --> E[Service B - your code] C --> F[Policy: retries, timeouts, mTLS, traffic splits] style A fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style B fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style C fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style D fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style E fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style F fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff

mTLS Without Code Changes#

Mutual TLS means both sides of a connection present certificates. Service A proves it’s who it says it is. Service B proves the same. Without a service mesh, adding mTLS to every service requires code changes in every service. With a sidecar, the proxy handles the TLS handshake. Application code never changes.

At Oracle#

Our 5G core network services had inconsistent retry behavior across teams. Some used Resilience4j. Some had hand-rolled retry loops with no jitter. One team had no retries at all. When we evaluated Istio for the platform, the feature that mattered most wasn’t traffic shifting. It was uniform retry and timeout policy across 20 services without any team needing to change their code.

What I’m Learning#

Service meshes add complexity. The sidecar consumes memory per pod. The control plane is another thing to operate. In small deployments, a shared networking library is simpler. Meshes make sense when you have enough services that policy consistency becomes the bigger problem than operational overhead.

Are you running a service mesh, and was the operational overhead worth it?