Service Mesh
Practice this topic in a realistic system design interview
Service-to-service communication becomes hard to manage once a system has many independently deployed services.
Each service needs the same basic network behavior: find the other service, prove who it is, encrypt the call, decide whether the call is allowed, set timeouts, retry safely, and emit useful logs, metrics, and traces. Putting all of that logic inside every codebase creates duplicated work and uneven behavior across languages and teams.
A service mesh moves a large part of that networking responsibility into the platform.
Applications still make normal HTTP, gRPC, or TCP calls. The mesh applies rules, records logs, metrics, and traces, and forwards traffic through a managed traffic path.
The goal is to handle internal service-to-service traffic consistently without rebuilding the same networking, security, and observability code in every service.
This chapter covers what a service mesh does, how the sidecar model works, and what it costs.
1. What a Service Mesh Is
A service mesh is an infrastructure layer for managing communication between services.
It usually has two parts:
- Data plane: The proxies or network agents that sit on the path of real requests. Think of this as the traffic layer.
- Control plane: The components that configure the data plane, issue identities, distribute rules, and connect with service discovery. Think of this as the configuration layer.
On the security side, the mesh can give each service instance an identity, encrypt traffic with mutual TLS, and enforce access rules. It can route and split traffic, then apply retries, timeouts, and automatic removal of unhealthy instances. It also produces metrics, access logs, and trace data, and it can control outgoing calls that leave the mesh.
The mesh does not remove the need for good application behavior. Services still need sensible timeouts, operations that are safe to retry, fallback behavior, compatible request and response formats, and business-level authorization.
2. Why Teams Add a Mesh
Without a mesh, each application owns its own networking behavior.
That model works for small systems. It becomes expensive when every language needs the same security rules, metrics format, retry behavior, certificate rotation, and traffic rollout mechanism.
With a mesh, platform policy moves closer to the network path.
The result is one consistent place to handle behavior that should not be rebuilt differently in every service.