A multi-product SaaS company with about forty services in three languages is evaluating a service mesh. Is it justified, and what would you check first?

What would justify it

The honest justifications are specific:

• Mutual TLS everywhere without touching applications. If a compliance requirement demands service-to-service encryption and identity, a mesh delivers it uniformly, and the alternative is a per-language project repeated three times and maintained forever.
• Consistent resilience policy across languages. Retries, timeouts, circuit breaking and outlier ejection implemented once. With three languages, library-based policy drifts by construction, and a platform-wide decision like a retry budget becomes impossible to make.
• Uniform, comparable telemetry at every hop. Frequently the most valuable outcome, because it makes latency attribution across the service graph possible for the first time.
• Traffic shifting for progressive delivery without application involvement.

What to check first

1. Is policy drift actually causing incidents? If retry behaviour is inconsistent but nothing has broken, the mesh is solving a theoretical problem. Look at the last ten incidents and ask how many a mesh would have prevented.

2. Could a shared library do it? With three languages, one well-maintained library per language is a real option and dramatically cheaper. The mesh wins as language count and team count grow — it is fundamentally a solution to a coordination problem, and that framing should be explicit.

3. Does the team have capacity to operate a control plane? A mesh control plane is a distributed system and a correlated failure domain: a bad configuration push can affect every service simultaneously. That is a new class of incident that did not previously exist.

4. What is the resource overhead? A sidecar per pod costs memory and CPU across the whole fleet, plus latency on every hop. At forty services this is manageable; the arithmetic is worth doing rather than assuming.

5. Is the real problem observability? Very often the pain is "we cannot tell which service is slow", and a mesh is being considered because it provides that as a side effect. Distributed tracing, adopted directly, may deliver the actual need at a fraction of the cost.

The recommendation for this size

Probably not yet, unless mutual TLS is a hard compliance requirement. Forty services in three languages is right at the boundary. The compelling case appears when the count of teams makes library upgrades take quarters — because at that point consistency is unattainable by agreement and must be structural.

If adopted, adopt incrementally: mutual TLS and telemetry first, since those deliver most of the value with the least risk, and traffic policy later once the team is comfortable operating the control plane.

The judgement being tested

Whether you can name the specific problem the mesh solves for this organisation, rather than adopting it because it is the mature pattern. A mesh is genuinely excellent technology and a substantial operational commitment, and the deciding factor is usually organisational — the number of teams and languages — rather than technical.