What a Service Mesh Does

A proxy beside every service

A service mesh is infrastructure for service-to-service communication. The data plane is a set of proxies, classically deployed as a sidecar container in each pod, that intercept all traffic in and out of a service and apply policy: mutual TLS, retries and timeouts, load balancing, circuit breaking, traffic splitting and telemetry. The control plane (the mesh brain) pushes configuration and certificates to those proxies. Because proxies do the work, services written in any language get the same behaviour without library changes. Popular meshes include Istio (Envoy proxies; a newer "ambient" mode avoids per-pod sidecars), Linkerd (its own lightweight Rust proxy), Consul and Cilium (eBPF-based). The cost: extra latency per hop, more moving parts and real operational complexity.

Control plane and data plane

Read it left to right: config flows down from the control plane; traffic flows through the proxies.

            [ control plane ]  <- policies, routes, certificates
              |   config / certs (xDS-style APIs)
   +----------+-----------+
   v                      v
[ proxy ] <== mTLS ==> [ proxy ]
[ orders ]            [ payments ]
  (service)             (service)

data plane = the proxies that carry traffic; services see plain local calls

Measure the overhead

Each sidecar hop adds a small amount of latency and CPU/memory. Measure p99 latency and resource cost with the mesh on and off before rolling it out widely.

Quick check: What is the data plane in a service mesh?

• The Git repository
• The dashboard
• The database
• The proxies that carry and police service traffic