What is the Service Mesh pattern and how do data-plane proxies such as Envoy implement it?

A Service Mesh is an infrastructure layer that handles all service-to-service communication concerns — traffic management, mutual TLS, retries, circuit breaking, observability — without requiring application code to implement any of it. It consists of two planes:

• Data plane — a sidecar proxy (Envoy, Linkerd-proxy) injected into every pod. All inbound and outbound network traffic for the application container flows through the sidecar. The sidecar applies policies, collects telemetry, and enforces mTLS transparently.
• Control plane — manages and configures the sidecar fleet (Istio Pilot, Linkerd control plane). It distributes routing rules, certificates, and traffic policies to each proxy. The control plane is never in the hot path of production traffic.

# Istio VirtualService — traffic splitting for canary release
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts: [reviews]
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10

What Envoy (data plane) handles per-request:

• mTLS — terminates inbound TLS and initiates outbound TLS with the peer's certificate, providing service identity without code changes.
• Retries and timeouts — configurable retry budgets and per-route timeouts enforced at the proxy level.
• Circuit breaking — ejects unhealthy upstream hosts from the load-balancing pool.
• Distributed tracing — propagates W3C traceparent headers and emits Zipkin-compatible spans.
• Traffic splitting — routes a percentage of traffic to canary versions of a service without touching application code.

The Service Mesh is appropriate when an organisation operates many services written in multiple languages and wants consistent, policy-driven networking without embedding SDK-level resilience logic in every service.