A service mesh is a dedicated infrastructure layer that manages service-to-service communication in a microservices architecture, handling concerns like routing, security, and observability outside of application code.
Key Points: • It's typically implemented using lightweight network proxies (sidecars) deployed alongside each service instance, which intercept all inbound and outbound traffic for that service. • It handles cross-cutting communication concerns — like retries, timeouts, load balancing, and circuit breaking — centrally and consistently, without every service needing to implement them individually. • It provides built-in security features such as mutual TLS between services, without requiring changes to application code. • It gives detailed observability into service-to-service traffic, including metrics, logs, and traces, often surfaced through a dashboard. • Popular implementations include Istio and Linkerd, usually deployed on top of Kubernetes.
Example: With Istio deployed on a Kubernetes cluster, every pod gets an Envoy sidecar proxy automatically injected; without changing any application code, the mesh can enforce mTLS between the Order and Payment services and report per-service latency and error rate metrics on a dashboard.
Interview Tip: A concise interview answer is:
"A service mesh is an infrastructure layer, usually implemented with sidecar proxies like Envoy, that handles service-to-service communication concerns — routing, retries, load balancing, mTLS, and observability — outside of application code. It's what lets teams get consistent security and resilience behavior across every service without each one reimplementing it."