Service Mesh

The pattern: a network layer that handles cross-service comms (mTLS, retries, traffic shaping, observability) without changing application code. Implemented via sidecars (Istio classic, Linkerd) or ambient (Istio Ambient), or eBPF (Cilium Service Mesh) — different ways to intercept service traffic.

The trade-off: uniformity vs. cost. A mesh gives you mTLS, traces, retries, canary rollouts, and access policies for free across the whole cluster — at the cost of CPU per request (sidecar) or kernel complexity (eBPF). For small clusters with <10 services, the mesh tax may not be worth it; at scale, the alternative (“every team rolls their own bad version”) is much worse.

Deepens in Year 2 Phase 12: Platform Engineering — UX + Security — Istio Ambient or Linkerd, with mTLS verified via tcpdump. The L3/L4 substrate it sits on comes from Year 1 Phase 2: Networking and Year 1 Phase 7: Kubernetes + GitOps, and the trace/metrics surface it produces is consumed in Year 3 Phase 14: Observability + eBPF.

Related patterns

• zero-trust-networking — the mesh is one of the few places mTLS actually lands at scale.
• load-balancing — meshes push L7 LB to per-pod proxies on every call.
• service-discovery — the mesh often takes the registry over from the app.
• network-policy — L3/L4 policy underneath; the mesh adds L7 authz on top.
• fault-isolation — retries, timeouts, circuit breakers as mesh primitives.
• defense-in-depth — identity + mTLS + L7 authz as additional layers in the stack.