Service mesh sidecar
The proxy (usually Envoy) injected as a sidecar beside each service in a service mesh and capturing all its network traffic. By sitting between the services it provides mTLS, traffic management, retries, and observability — without changing the application code.
Mechanic: the mesh (Istio, Linkerd) automatically injects a proxy sidecar into each pod; all in/outbound traffic is routed through it. The proxies (the data plane) are controlled centrally by a control plane. What they provide "for free": mTLS (automatic mutual encryption between services), traffic management (canary, weighted routing, fault injection), resilience (retries, timeouts, circuit breaking), and observability (metrics, traces, logs for all service-to-service traffic). Trade-off: one proxy per pod = resource overhead and latency, plus operational complexity → which is why "sidecar-less" meshes (Istio Ambient, Cilium) are growing, moving the function to the node/eBPF. The dominant pattern for service-to-service communication in large clusters. Related to sidecar container and network policy.