Service Mesh
Moving retries, mTLS and traffic control out of every service and into the platform — and when that is not worth it.
The Same Five Problems In Every Service
The mesh splits into a data plane — the proxies that carry traffic — and a control plane that configures them. Your service talks to localhost; the proxy handles encryption, routing, retries and metrics, and the application code knows nothing about any of it.
The Sidecar Model
A proxy runs in every pod and intercepts all traffic in and out. That is what makes the mesh language-agnostic: a Go service, a Python service and a legacy Java service get identical behaviour without one of them adding a dependency.
| Buys | Costs |
|---|---|
| One implementation of retries and timeouts | A proxy's CPU and memory in every pod |
| Consistent behaviour across languages | A hop of latency on every call |
| Policy changed without redeploying services | Substantial operational complexity |
| Uniform metrics and traces | A new failure domain to debug |
mTLS & Zero Trust
The strongest argument for a mesh is usually security. It issues a certificate per workload and encrypts every service-to-service call with mutual TLS — both sides prove identity — with rotation handled automatically.
| Gives | Instead of |
|---|---|
| Encryption in transit everywhere | Plaintext inside the cluster perimeter |
| Cryptographic workload identity | Trusting whatever IP connected |
| Policy: A may call B, not C | Network rules that drift from intent |
| Automatic certificate rotation | An expiry outage every two years |
This is what "zero trust" means concretely: being inside the network grants nothing, because every call is authenticated and authorised on its own merits.
Traffic Control & Observability
Because the proxy sees every request, it can route on any property of it — which is what makes canaries, mirroring and fault injection a configuration change rather than an application feature.
| Capability | Use |
|---|---|
| Weighted splitting | Canary releases without touching code |
| Header-based routing | Route staff or a test cohort to a new build |
| Mirroring | Send a copy of live traffic to a new version |
| Retries, timeouts, circuit breaking | Resilience policy, applied uniformly |
| Fault injection | Chaos experiments as configuration |
The mesh also produces uniform request metrics and trace spans for every service, which is how a service map gets built without instrumenting anything — although the application still has to propagate trace context.
When Not To
| Situation | Verdict |
|---|---|
| Fewer than about ten services | Libraries and defaults are cheaper |
| One language across the estate | A shared library gets most of the benefit |
| No platform team to operate it | Do not — an unowned mesh is an outage source |
| mTLS mandated by compliance | Strong reason to adopt |
| Polyglot, many teams, real traffic policy | This is what a mesh is for |
Interview Questions
What problem does a service mesh solve?
It implements retries, timeouts, mTLS, load balancing and telemetry once in a proxy beside every service, instead of once per language in every service.
Data plane versus control plane?
The data plane is the proxies carrying traffic; the control plane configures them. Policy changes are applied to the control plane and take effect without redeploying services.
What does mTLS give you inside a cluster?
Encryption in transit plus cryptographic workload identity, so authorisation is based on who the caller is rather than what network it came from — the concrete meaning of zero trust.
Why are layered retries dangerous?
They multiply. Three retries in the mesh and three in the client is nine attempts, amplifying load against a service that is already failing.
What does a mesh cost?
A proxy per pod in CPU and memory, a hop of latency on every call, real operational complexity, and a new failure domain to debug.
When should you not adopt one?
With few services, a single language, or no platform team to operate it. A mesh moves duplicated complexity into one place; it does not remove it.