What is a service mesh, and do you have enough services to need one?

A service mesh is a layer of proxies that handles communication between your services, including retries, timeouts, encryption, tracing and traffic routing. A proxy sits beside each service, your code makes a plain call, and the proxy applies the policy. You need one when inconsistent service-to-service behaviour or a security requirement costs more than running the mesh.

These concerns are identical across services, tedious to build and inconsistent when each service handles them itself. The cost is a proxy per service, a control plane (the part that configures every proxy) to operate, and a layer between your code and the network that stays invisible until it is the problem.

What we'll cover

• What it actually does
• The sidecar, and what it costs
• Mutual TLS, the usual reason
• Traffic control
• Observability that comes free
• The alternatives
• Do you have enough services
• Adopting one without a bad week
• Automating around services with CodeWords
• What to get right first
• Frequently asked questions

Key takeaways

• A service mesh applies retries, encryption, identity, routing and telemetry to service-to-service traffic through a proxy beside each service.
• The proxies cost memory, processor time, latency and operating effort on every instance.
• Mutual TLS (encrypted calls where both sides prove their identity) is the most common reason to adopt a mesh.
• A mesh covers traffic between services only. Traffic arriving from outside is the job of an API gateway.
• Name the specific problem first, because shared libraries or platform features often solve it with less overhead.

What it actually does

A service mesh applies seven capabilities to service-to-service calls, configured in the mesh and not coded in each service:

• Retries and timeouts apply consistently to every call.
• Circuit breaking stops calls to a failing dependency instead of hammering it while it recovers.
• Encryption between services works without each service managing certificates.
• Identity per service lets a call be authenticated by which service made it, not by a shared secret.
• Traffic routing sends a share of requests to a new version, splits by header or mirrors traffic.
• Telemetry records metrics and traces for every call without instrumenting each service.
• Scope is service-to-service traffic only. Calls from outside belong to the gateway, a common point of confusion.

The sidecar, and what it costs

The sidecar model puts one proxy beside each service instance, and the costs are real:

• Resource overhead per instance. A proxy uses memory and processor time, multiplied by the number of instances you run.
• Added latency per hop. The delay is small individually and meaningful across a call chain of five services.
• Another component to upgrade, in step with the control plane, across every service.
• Another place a request can fail. Proxy failures confuse people because the service's own logs show a call that never left.
• A steep learning curve. Debugging a mesh requires understanding it, so the team that adopted it for simplicity now has a new specialism.

Proxyless and node-level variants exist. They trade the per-instance overhead for different limitations, so check them before assuming the sidecar is the only shape.

Mutual TLS, the usual reason

Mutual TLS is the usual reason to adopt a mesh because it encrypts every service call and authenticates both sides, with certificates issued and rotated by the mesh. Issuing, distributing and rotating certificates for every service by hand is work nobody wants.

• It gives each service an identity, so policy can state which services may call which, enforced and not merely documented.
• It often satisfies a compliance requirement for encryption and access control between services.
• State the reason. A mesh adopted for encryption and identity is a sound decision. A mesh adopted because it appeared on an architecture diagram is not, and the difference shows in whether anyone maintains it.

Traffic control

Traffic control in a mesh covers four techniques:

• Weighted routing sends a share of traffic to a new version, the mechanism behind canary releases at the service level.
• Header-based routing sends specific requests, such as a test account or an internal user, to a particular version.
• Mirroring sends a copy of live traffic to a new version without its responses affecting anyone, which tests a release under real load.
• Fault injection introduces failures and delays on purpose, so you verify that the system handles them.

These techniques are valuable and not free. At smaller scale, other tools achieve most of them, which is the recurring theme of this decision.

Observability that comes free

A mesh gives observability without changing your services, because every call passes through a proxy that measures it.

• Every call is measured: latency, error rate and volume per service pair.
• The dependency graph becomes visible, derived from actual traffic and not from a diagram someone drew.
• Traces propagate through the proxies, but your services must still pass the trace headers along for a trace to be complete.
• It is often the most useful early benefit, particularly where nobody is certain what calls what.
• It does not replace application instrumentation. The mesh sees calls, not what happened inside them, and a slow call does not say why.

The alternatives

Four alternatives cover much of what a mesh provides:

Alternative	What it covers	Where it falls short
Shared client library	Retries, timeouts, circuit breaking	Becomes an upgrade problem across many languages
The platform	Encryption in transit, health checks, basic routing (managed load balancers, container platforms)	Less fine-grained policy
A gateway	Traffic entering from outside	Does not cover service-to-service calls
Instrumentation libraries	Tracing without a mesh	More work per service, more control

Doing less also works: fewer services means fewer inter-service calls, and the value of a mesh is proportional to how much of that traffic exists.

Do you have enough services

You have enough services for a mesh when inconsistent service-to-service behaviour or a security requirement costs more than operating one. Service count is a rough guide only, and the threshold is higher than the online discussion implies.

• Fewer than about ten services: probably not. A shared library handles the consistency problem, and the proxy overhead is disproportionate. This is an editorial rule of thumb, not a measured figure.
• One language across all services weakens the case, because a library solves it without a proxy per instance.
• No platform team: no. A mesh needs someone who understands it, and an unmaintained mesh breaks things nobody can diagnose.
• A compliance requirement for encryption and identity: the case is strong at any service count.
• Adopt incrementally. Apply the mesh to a subset of services first to learn whether it helps.

Ask which specific problem you are solving, and what it would cost to solve it another way.

Adopting one without a bad week

Adopt a mesh in a fixed order, which avoids most of the pain:

1. Start in a non-production environment, long enough that someone understands the failure modes before production does.
2. Enable it on a few services that talk to each other, so the mesh does real work.
3. Turn on observability first. It is the lowest-risk capability and delivers value immediately.
4. Enable encryption in permissive mode before enforcing it, so services outside the mesh keep working.
5. Add traffic policy last. Retries and circuit breaking change behaviour, and changing behaviour while introducing a new component is two changes at once.
6. Watch resource use as you expand, and measure the per-instance overhead instead of estimating it.
7. Keep a way to disable it per service, and test that it works.

Automating around services with CodeWords

Much of the work around a service estate is integration, not infrastructure: reporting across services, connecting them to business systems and reacting to what they emit. CodeWords connects to 3,000+ integrations (CodeWords integrations page, 2026).

1. Open CodeWords and start a new automation.
2. Describe in plain language what should happen, to Cody, the automation builder.
3. Describe the exceptions explicitly.
4. Connect the systems involved once and reuse the connections.

You describe the outcome, and Cody builds it, connects it and deploys it. The Free plan covers light use. Pro costs $39 per month and Business costs $100 per month (CodeWords pricing page, 2026). Details are on the pricing page.

What to get right first

Name the specific problem before evaluating a mesh. "Inconsistent retries", "we need encryption between services for compliance" and "nobody knows what calls what" are different problems with different best answers, and only some point at a mesh. A mesh adopted without a named problem is a component nobody maintains.

Two habits make the difference. Adopt it on a subset of services first, since that shows the operating cost before you commit the whole estate. And remember it covers service-to-service traffic only: if the problem is traffic arriving from outside, a gateway is the answer.

Frequently asked questions

What is the difference between a service mesh and an API gateway?

A gateway handles traffic entering your system from outside, and a mesh handles traffic between your services. They solve different problems and are often used together. Confusing the two is the most common misunderstanding about service meshes.

How many services justify a mesh?

As a rough editorial guide, more than about ten, though the count matters less than the specifics. Several languages strengthen the case, a single language weakens it, and a compliance requirement for encryption and identity makes the case strong at any size.

What does the sidecar actually cost?

The sidecar costs memory and processor time per instance, latency per hop, another component to upgrade across every service, and another place a request can fail. Proxy failures confuse people because the service's own logs show a call that never left.

Is mutual TLS the main reason to adopt a mesh?

For many organisations, yes. Issuing, distributing and rotating certificates across every service by hand is painful. A mesh does it automatically and attaches a service identity, which often satisfies a compliance requirement.

Can I get the benefits without a mesh?

Much of them. Shared libraries handle retries and circuit breaking, platforms handle encryption and health checking, gateways handle external traffic, and instrumentation libraries give tracing. The mesh's advantage is consistency across many languages and services.

Does a mesh give me full observability?

No. A mesh gives you every call's latency, error rate and volume, plus the real dependency graph, which is more than most estates have. It sees calls and not what happened inside them, so it complements application instrumentation.

What if nobody owns the mesh?

Do not adopt one. A mesh needs someone who understands it, and an unmaintained mesh becomes a layer between your code and the network that breaks things nobody can diagnose.

What order should I enable mesh features in?

Enable observability first, because it is the lowest-risk capability and delivers value at once. Then enable encryption in permissive mode before enforcing it. Add traffic policy last, because retries and circuit breaking change behaviour.

What should I verify before expanding a mesh?

Verify that you can disable it per service and that disabling works. Also measure the per-instance resource overhead on real services instead of estimating it, since that number determines the cost of full adoption.

Are there alternatives to the sidecar model?

Yes. Proxyless and node-level variants trade the per-instance overhead for different limitations. Understand them before assuming a proxy beside every instance is the only available shape.

Related reading

• API gateways
• Microservices vs monolith
• Platform engineering