// Communication & Integration · 09
Service Mesh
Retries, encryption, and routing pulled out of your code entirely.
How it fits together
- Orders uses / calls Orders proxy (1 request)
- Orders proxy uses / calls Inventory proxy (2 mTLS)
- Inventory proxy uses / calls Inventory (3 local call)
- Control plane uses / calls Orders proxy (push config)
- Control plane uses / calls Inventory proxy (push config)
Spot it
- Every service hand-rolls retries and TLS
- Nobody can see which service calls which
- Canary releases need code changes to route
It costs
Another platform layer to run and upgrade, plus a small latency cost on every hop.
Go deeperThe full explanation and what to ask for · 1 min readExpandCollapse
A mesh puts a proxy in the path of every service-to-service call, the data plane, and configures all of them from a control plane. Mutual TLS, retries, timeouts, load balancing and per-call metrics then happen without changes to application code.
The classic mistake is adopting one for a handful of services: the operational cost is real, and a shared client library may be enough. Another is stacking retries: if the app and the mesh both retry, attempts multiply. Pick one layer.
The mesh handles east-west traffic inside the cluster; an API gateway handles north-south traffic from outside. Most meshes are built on the sidecar pattern, though some newer designs move the proxy into a per-node component.
Ask for it
- data plane / control plane
- sidecar proxy
- mTLS
- traffic splitting
- golden metrics
- east-west traffic
Add a mesh (Istio, Linkerd) to the orders namespace in Kubernetes: inject proxies, require mTLS between meshed pods, set a timeout and retry policy on the inventory route, send 10% of traffic to inventory v2 as a canary, and chart success rate, requests per second and p99 latency per service.