service mesh pattern
A network of sidecar proxies (Envoy, Linkerd) plus a control plane (Istio, Consul). Each service's traffic flows through its sidecar, which handles retries, timeouts, mTLS, observability, traffic shaping. Cross-cutting concerns become platform concerns; application code stays focused. Cost: operational complexity, latency tax, debugging through extra hops.
A network of sidecar proxies (Envoy, Linkerd) plus a control plane (Istio, Consul). Each service's traffic flows through its sidecar, which handles retries, timeouts, mTLS, observability, traffic shaping. Cross-cutting concerns become platform concerns; application code stays focused. Cost: operational complexity, latency tax, debugging through extra hops.
symptoms
- cross-cutting concerns scattered across many services in many languages
- inconsistent retry/timeout behavior across services
- platform team can't roll out improvements without service-team coordination
causes
- language polyglot prevents shared libraries
- no shared infrastructure layer for service-to-service
fixes
- service mesh: sidecar per service, control plane for config
- mTLS, retries, observability all centralized
- app code is language-agnostic
you might say
- service mesh
- sidecar mesh
- control plane / data plane