Service Mesh Primer
Understand the sidecar pattern, mutual TLS, and traffic splitting before you deploy Meridian into a mesh.
What is a service mesh?
A service mesh is a dedicated infrastructure layer that handles service-to-service communication. Instead of baking retry logic, circuit breakers, and TLS into every application, the mesh offloads those concerns to a sidecar proxy — typically Envoy — that runs alongside each workload.
The sidecar pattern
Every pod gets a lightweight proxy container injected automatically. Your application talks to localhost:15001 instead of reaching other services directly. The sidecar intercepts all inbound and outbound traffic, enforces policy, and emits telemetry without a single line of application code.
Mutual TLS (mTLS)
The mesh provisions short-lived X.509 certificates to every sidecar via a control-plane CA. When mTLS is enabled, all inter-service traffic is encrypted and authenticated transparently. Meridian's licensing heartbeat runs over this encrypted fabric, so license tokens never traverse the wire in plaintext.
Traffic splitting
Canary deployments become trivial. Define a VirtualService that sends 5% of traffic to the new revision and 95% to stable. The mesh respects these weights at the Envoy level, so you can validate Meridian updates against a fraction of real users before rolling out globally.
Observability for free
Because every request flows through the sidecar, the mesh emits latency histograms, request counts, and error rates without instrumentation. Meridian's dashboard consumes these metrics to surface license-validation latency and injection-detection throughput in real time.
Next step
Ready to wire Meridian into your mesh? Read the Istio deployment guide for a step-by-step walkthrough with sample manifests.