The problem a mesh solves
In a microservices system, every service must handle retries, timeouts, encryption, and metrics for its calls to other services. Building that into each app is repetitive and error prone.
A service mesh moves this logic out of the application and into a dedicated infrastructure layer.
Sidecar proxies
The mesh injects a sidecar proxy next to each service instance. All inbound and outbound traffic flows through the proxy, so the application code stays focused on business logic.
- Data plane the sidecar proxies that carry the actual traffic.
- Control plane configures all the proxies with policies and certificates.
What it provides
- Traffic control retries, timeouts, and weighted routing for canary releases.
- Security automatic mutual TLS encryption between services.
- Observability consistent metrics, logs, and traces for every call.
The cost is added complexity and a small latency overhead from the extra network hop through each proxy. For large fleets the consistency usually outweighs it.
Key idea
A service mesh uses sidecar proxies and a control plane to handle retries, encryption, and observability uniformly, keeping that cross cutting logic out of application code.