Sidecar Overhead
The latency, memory and failure surface a mesh proxy adds per pod, which is the price of what the mesh provides and is frequently unmeasured.
A sidecar proxy intercepts every inbound and outbound connection. That buys mTLS without application changes, uniform retries and timeouts, traffic shifting, and consistent telemetry. It costs a hop in each direction — typically low single-digit milliseconds — plus tens to hundreds of megabytes of memory per pod, multiplied by every pod in the fleet.
Two effects are less obvious than the resource cost. The proxy is a new failure surface: a misconfigured retry policy applied uniformly can amplify a downstream incident across the entire mesh, and proxy startup ordering races with the application container in ways that produce confusing intermittent failures. And the control plane becomes a critical dependency whose own availability now bounds the fleet's.
The question worth asking before adopting one is which of the mesh's capabilities are actually needed. If the answer is mTLS alone, there are cheaper routes. If it is mTLS plus traffic shifting plus uniform policy across many languages, the overhead is usually worth paying — but it should be a measured decision, and the measurement is rarely taken.