Inter-service communication infrastructure

Enables consistent, observable, and resilient communication between microservices without embedding networking logic in application code.

Microservices: managing cross-service communication across 10+ services with uniform policies Cloud-native: enforcing mTLS, retries, and traffic routing uniformly across a Kubernetes cluster Distributed systems: adding tracing, metrics, and failure handling to inter-service calls without app changes

Kubernetes, Istio, Linkerd, Envoy, Consul, microservices architectures, cloud-native infrastructure, SRE platforms

deploy sidecar proxies alongside services → configure traffic, security, and observability policies → observe and control inter-service communication

• sidecar proxy
• mTLS
• traffic management
• observability
• circuit breaking
• retries
• load balancing
• Istio
• Linkerd
• Envoy
• Kubernetes
• east-west traffic

• API gateway: handles north-south traffic at the edge vs service mesh handles east-west traffic between services Shared client libraries: embed logic in application code vs service mesh offloads to infrastructure layer ESB / message broker: legacy centralized hub-and-spoke vs decentralized sidecar-per-pod pattern

Treating service mesh as a replacement for API gateway: they serve different traffic directions (east-west vs north-south) and complement each other Adding service mesh to a monolith: unnecessary operational complexity for a single deployable unit Assuming zero application changes: some apps must adapt to mTLS peer identity or injected headers Ignoring sidecar overhead: each proxy adds 1–3 ms latency and CPU/memory per pod, which matters at scale Confusing service mesh with service registry: registry only tracks service locations, mesh manages the full communication contract

API gateway: edge proxy for external traffic vs service mesh for internal service-to-service Shared client libraries: in-process logic vs out-of-process sidecar Service registry: discovery only vs service mesh: discovery plus communication policies SDN: network-level routing vs service mesh: L7 application-level routing with service identity

Coming from monolithic applications: may try to add service mesh to a single deployable — service mesh only pays off with multiple independently deployed services Coming from traditional networking: may confuse with SDN or hardware load balancer — service mesh operates at L7 with cryptographic service identity, not just IP/port routing Coming from ESB-era Java: may expect a centralized broker — service mesh is decentralized, with a proxy per pod

• sidecar proxy
• API gateway
• service discovery
• mTLS
• circuit breaker
• distributed tracing
• control plane
• data plane

When NOT to use: small fleets (under ~10 services) where shared libraries are simpler; latency-critical paths where sidecar hop overhead is unacceptable; teams without Kubernetes operational maturity Performance: each sidecar adds roughly 1–3 ms latency per hop and consumes CPU/memory proportional to request volume; ambient or eBPF modes reduce this Boundary conditions: requires container orchestration (typically Kubernetes); certificate rotation and control-plane upgrades add operational surface area; not all protocols are supported equally (HTTP/gRPC first-class, others via plugins)

Decouples cross-cutting communication concerns from business logic, enabling uniform mTLS, canary/A-B traffic splits, and distributed tracing across hundreds of services without redeploying application code.

Service mesh: like a dedicated postal system for your microservices — every letter (request) passes through a local sorting office (sidecar proxy) that handles retries, security stamps, and tracking, so the actual services never need to learn how mail works.

eBPF-based service mesh (Cilium service mesh) or Istio ambient mesh mode — both eliminate per-pod sidecars for lower latency and resource cost