Service Mesh
What is it?
A service mesh is an infrastructure layer that handles communication between microservices — routing, security, and observability — without changing the app code.
Explain like I'm 5
Why was it created?
As microservices multiplied, each had to re-implement retries, encryption, and monitoring. A service mesh was created to move that into shared infrastructure.
Where is it used?
- Large microservice systems
- Securing service-to-service traffic
- Traffic control (retries, routing)
- Cross-service observability
Why should developers care?
Service meshes are common in large Kubernetes deployments, so platform and senior engineers should understand their role and cost.
How does it work?
A small proxy (a 'sidecar') runs next to each service and intercepts its network traffic. These proxies, managed by a control plane, handle encryption, retries, load balancing, and metrics — so the app code doesn't have to.
Real-world example
A mesh automatically encrypts all traffic between services and retries failed calls, while giving uniform metrics — without developers writing that logic.
Common use cases
- Mutual TLS between services
- Automatic retries and routing
- Uniform observability
- Traffic shifting for canaries
Advantages
- Consistent security and reliability
- No app code changes
- Built-in observability
- Fine-grained traffic control
Disadvantages
- Significant complexity
- Resource overhead from sidecars
- Steep learning curve
- Often overkill for small systems
When should you use it?
For large microservice fleets needing consistent security, reliability, and observability.
When should you avoid it?
For a few services, where the complexity outweighs the benefit.
Alternatives
Related terms
Interview questions
Beginner
- What is a service mesh?
- What is a sidecar proxy?
Intermediate
- What concerns does a mesh handle?
- What is mutual TLS?
Senior
- What are the costs of running a service mesh?
- When is a mesh overkill?
Common misconceptions
- "A service mesh replaces an API gateway" — a gateway handles edge/north-south traffic; a mesh handles service-to-service east-west traffic.
- "Every microservice system needs a mesh" — small systems often don't justify the overhead.
Fun facts
- The per-service proxy is called a sidecar.
- A mesh splits into a data plane (the proxies) and a control plane (that configures them).
Timeline
- 2017 — Service mesh tooling gains popularity in the Kubernetes ecosystem
Learning resources
Quick summary
A service mesh moves cross-cutting service-to-service concerns — security, retries, observability — into a sidecar-based infrastructure layer, no app changes needed.
Cheat sheet
- Infra layer for service-to-service comms
- Sidecar proxies + control plane
- Security, retries, observability
- Powerful but complex