service-mesh
A service mesh mediates service-to-service traffic through an infrastructure data plane and distributes policy through a control plane.
- Data planeMediates every internal connection and enforces policy.
- Control planeDistributes identity, certificates, and configuration.
- Application signalProves business effect beyond transport telemetry.
Context
Why this is important
The mesh standardizes identity, encryption, telemetry, and traffic rules without knowing application business error semantics.
The distributed extension in the shop scenario is hypothetical; the current shop remains a modular monolith with seven modules and one shared database.
Service Mesh: decision boundaries
The current shop remains with seven modules in one process and does not need a mesh. For hypothetical separate Order, Payment, and Shipping services, a mesh data plane mediates mTLS, telemetry, and traffic rules. The team rotates certificates, disconnects the control plane, and forces a target outage. It measures added p95 latency, connection errors, and behavior with last known configuration before the platform complexity is justified.
This is how you read the picture
- Data plane Proxy in call path
- Control plane Define outage behavior
- Application signal Trace plus business metric
| Comparison | Aspect | Sound use | Limit |
|---|---|---|---|
| Many services | Uniform internal identity and policy | Shared platform operation | Added latency and resources |
| Few services | Direct library or platform capability | Fewer moving parts | Mesh benefit often too small |
| Control-plane outage | Last known policy remains active | Tested degradation mode | Changes and certificates may stall |
Benefits & limitations
Helps if:
- Shared platform operation
- Fewer moving parts
- Tested degradation mode
Boundaries
- Added latency and resources
- Mesh benefit often too small
- Changes and certificates may stall
In practice
- Apply an internal identity and encryption policy between order and payment services. Check certificate rotation and failure handling at both ends.
- Measure added latency and observe a connection failure through data plane and control plane. Compare the view with application metrics.
- Compare mesh policy with direct library configuration. Assess whether uniform control justifies platform operations for the number of services.
Read the detailed explanation
Proxies or node-local components intercept internal connections, authenticate peers, and apply policies. The control plane distributes identities, certificates, and routing configuration.
A mesh adds latency, resource use, and new failure modes. Application traces and business metrics remain necessary because infrastructure telemetry does not prove a successful order.
Service Discovery supplies targets; Timeouts must share one time budget between mesh and application.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
What is the core task of Service Mesh?
View the solution with justification
A service mesh mediates service-to-service traffic through an infrastructure data plane and distributes policy through a control plane.
ApplyingTransferred to a new situation
Which assumption is hypothetical in the shop?
View the solution with justification
For hypothetical separate Order, Payment, and Shipping services, a mesh data plane mediates mTLS, telemetry, and traffic rules. The team rotates certificates, disconnects the control plane, and forces a target outage.
EvaluateWeighing an alternative
Which three points require evidence before adoption?
View the solution with justification
Data plane, Control plane, Application signal.
Explore further
These building blocks continue the thoughts of this page.