Service Mesh
A dedicated infrastructure layer for service-to-service traffic.
AdvancedPlatform
Every service gets a sidecar proxy handling mTLS, retries, load balancing and telemetry for all its traffic, all controlled centrally by a control plane -- moving networking concerns out of application code entirely.
When to use it
- Dozens of services need consistent mTLS, retries and traffic policy without per-service code
- You need fine-grained traffic shaping (canary, mirroring) at the infrastructure layer
Trade-offs
- Meaningful operational complexity and resource overhead for smaller service counts
- Debugging traffic issues now spans app code, sidecar and control plane
Components used
Service MeshContainer Service
How it works
- Every service instance gets a proxy that intercepts all inbound and outbound traffic, forming the data plane.
- A control plane distributes policy — routing rules, mTLS certificates, retry and timeout configuration — to every proxy.
- Traffic management, encryption and telemetry become infrastructure concerns rather than application code.
Used in the wild
- Large microservice estates needing consistent mTLS without touching every service.
- Fine-grained traffic shifting for canaries and A/B tests at the network layer.
- Uniform golden-signal telemetry across services nobody wants to re-instrument.
Good to know
- It is essentially the sidecar pattern applied uniformly plus a control plane to configure it centrally.
- The operational complexity is significant and frequently underestimated. Below roughly a few dozen services, a mesh usually costs more than it returns.
Related patterns
Model Serving with A/B Testing
Route inference traffic across model versions to compare live performance.
CQRS
Separate models and stores for writes and reads.
Blue-Green Deployment
Run two full production environments, switch traffic between them.
Canary Release
Send a small slice of traffic to the new version before a full rollout.