A team proposes adopting a service mesh for twelve services in one language. Do you support it?

What the interviewer is testing

Whether you can price operational complexity against capability rather than adopting a technology because it solves problems you have.

The case against, at this scale

The mesh's benefits — mTLS everywhere, uniform retries and timeouts, fine-grained traffic shifting, consistent telemetry across languages — are real, and the last one is doing most of the work in the usual justification. With one language, a shared client library achieves most of it at a fraction of the operational surface.

The costs at twelve services:

• A control plane with its own upgrade cycle, failure modes and expertise requirement
• A proxy in the request path of every call, so every debugging session now has four candidate layers: application, sidecar, control plane, policy
• Sidecar resource overhead per pod and roughly a millisecond per hop
• Mesh misconfiguration produces some of the most confusing failures in modern operations, because traffic is being altered by a component the application team did not know was there

The first control-plane upgrade is usually when teams reconsider.

What to do instead

mTLS: many managed platforms provide it at the ingress and between nodes; for service-to-service, a shared library or the platform's own workload identity covers it. Network policy: native Kubernetes policy gives default-deny and explicit allow. Retries and timeouts: a shared client library, which also gives deadline propagation that a mesh does not do well. Observability: an OpenTelemetry SDK, which gives richer application-level context than a proxy can infer.

When the answer changes

Many services, multiple languages, and a hard mTLS or traffic-policy requirement — roughly the point where writing the same client behaviour four times becomes the larger cost.

What a strong answer adds

Sidecar-less modes materially reduce the overhead argument and do not reduce the control-plane complexity argument, which is the larger one at this scale.

Common weak answers

Adopting it because it is the standard pattern for microservices. Rejecting it on CPU overhead alone, which is the weakest of the objections.