Service Mesh & Sidecar Proxy
Networking & DeliveryInfrastructure-layer handling of service-to-service traffic (retries, mTLS, load balancing, circuit breaking, tracing) via a sidecar proxy next to every service instance, without changing application code.
As microservice fleets grow, every service ends up needing the same cross-cutting networking concerns: retries with backoff, mutual TLS between services, load balancing across instances, circuit breaking, and distributed tracing headers. A service mesh implements all of this once, in infrastructure, by deploying a lightweight proxy ('sidecar', e.g. Envoy) alongside every single service instance; all traffic in and out of the service flows through its sidecar, which handles these concerns transparently. A control plane (e.g. Istio's control plane) configures all the sidecars' routing/security/retry policy centrally, so application code stays completely unaware of the mesh.
How it connects
Service Mesh & Sidecar Proxy as the source, with the components it typically interacts with.
- → Forward & Reverse Proxy: A service mesh's data plane is built from per-service sidecar reverse proxies (Envoy) that intercept all inbound/outbound traffic.
- → Circuit Breaker & Bulkhead: Meshes implement circuit breaking, retries, and timeouts as sidecar configuration, removing that logic from application code.
- → Observability (Logs, Metrics, Traces): Meshes provide uniform, automatic tracing/metrics for every service-to-service call since all traffic already passes through the sidecar.
- → Service Discovery: The mesh's control plane relies on service discovery to know which endpoints exist and push that routing information to every sidecar.