Explain Service Mesh in Microservices

3 / 12

communication

Service Mesh

Push cross-cutting concerns (retries, mTLS, traffic shifting, observability) into a sidecar proxy so application code stays focused on business logic.

As a microservices estate grows, every service ends up needing the same networking concerns — retries, timeouts, mutual TLS, load balancing, traffic shifting, and telemetry — and implementing them in each service's code, in every language, is repetitive and inconsistent. A service mesh moves all of that out of the application and into the infrastructure layer, so the networking behaviour is uniform and managed centrally while the business code stays clean.

A universal translator clipped to every diplomat: they speak their own language while the device handles security, retries, and recording uniformly for every conversation.

Key Concepts

The mesh works by deploying a sidecar proxy (commonly Envoy) alongside each service instance — in Kubernetes, a second container in the same pod. All of the service's inbound and outbound traffic is transparently routed through its sidecar, and the sidecars form the data plane that actually carries requests between services. A separate control plane (such as Istio or Linkerd) configures all the sidecars from one place. Because every call passes through a proxy, the mesh can enforce mutual TLS between services without the application knowing, apply consistent retry and timeout and circuit-breaking policies, shift traffic for canary and blue-green releases by weight, inject faults for chaos testing, and emit uniform metrics, logs, and traces for every hop — all configured declaratively rather than coded into services.

The judgement interviewers reward is knowing when a mesh is worth it. It delivers consistent, language-agnostic resilience, security, and observability without touching application code, which is powerful at scale — but it adds real operational complexity and a per-hop latency and resource cost from the proxies. For a handful of services, library-based resilience (like Resilience4j) is often simpler; the mesh earns its keep when you have many services in multiple languages and want to govern their communication centrally. It is also worth distinguishing it from an API gateway: the gateway handles north-south edge traffic, the mesh handles east-west service-to-service traffic.