A service mesh is a dedicated layer that handles communication between services in a microservices system. Lightweight proxies, commonly deployed as sidecars beside each service instance, intercept traffic, while a control plane distributes configuration to them.
Why it matters
As the number of services grows, every one needs the same plumbing: encrypted connections, timeouts, retries, traffic splitting and metrics. A mesh provides these consistently instead of each team re-implementing them in different languages. Typical features include mutual TLS between services, canary traffic shifts and detailed latency data per call. Istio and Linkerd are widely known examples.
The cost is complexity and resource use: extra proxies add CPU, memory and a new thing that can fail or be misconfigured.
Example
A traffic rule that sends 5 percent of requests to a new version:
service: checkout
v1: 95%
v2: 5%If error rates for v2 rise, the rule is changed back with no redeploy of the application itself.
Common mistakes
- Adopting a mesh for a handful of services, where a library or ingress would do.
- Setting aggressive retries that multiply load during an outage.
- Not monitoring the proxies themselves.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.