Data Plane & Control Plane

A service mesh has two planes. The data plane consists of sidecar proxies deployed alongside every service instance — every network call flows through the proxy, which handles retries, timeouts, circuit breaking, mTLS, and observability transparently. The control plane configures the proxies: routing rules, security policies, and traffic management. The application code makes plain HTTP calls; the sidecar handles the complexity. This separation is the architectural value — communication resilience without communication code.

1. Data Plane The sidecar proxy intercepts all inbound and outbound traffic for the service. Envoy is the most common data plane proxy — high performance, extensible, protocol-aware. Each service instance has its own proxy, creating a network of proxies that collectively form the mesh. The data plane is the enforcement layer — it executes the policies that the control plane defines.
2. Control Plane The control plane manages proxy configuration: which routes are available, which retry policies apply, which services can communicate with which. Istio, Linkerd, and Consul Connect are control plane implementations with different operational models. The control plane is the management layer — it defines the policies that the data plane enforces.
3. The Operational Model The mesh adds a new infrastructure layer. Sidecar proxies consume CPU and memory on every node. The control plane requires its own deployment and monitoring. Configuration errors in the control plane affect every service in the mesh. The operational model is: can your team manage this additional infrastructure layer? If the answer is uncertain, start with a library-based approach and migrate to a mesh when the team has the capacity.