Service Mesh Architecture: Mermaid Diagram

Service Mesh Architecture flowchart diagram

About Source

A service mesh is a dedicated infrastructure layer that handles service-to-service communication in a microservices deployment, providing traffic management, observability, and security without requiring changes to application code.

What the diagram shows

The diagram is split into two planes: the Data Plane and the Control Plane. In the data plane, each microservice — Service A, Service B, and Service C — is paired with a Sidecar Proxy (typically Envoy). All network traffic between services flows through these proxies rather than directly between the application containers. The sidecar handles TLS termination, load balancing, retries, and circuit breaking transparently.

The Control Plane (represented here as a single Mesh Control Plane node, e.g. Istio, Linkerd, or Consul) pushes policy and configuration down to every sidecar. It also collects telemetry — metrics, traces, and access logs — and feeds them to an Observability Backend for dashboards and alerting.

Why this matters

Before service meshes, every team had to implement retries, timeouts, and mutual TLS inside their own service. A mesh externalizes that logic into the infrastructure layer, making it consistent across all services regardless of programming language. The trade-off is added latency (one extra network hop per call through the sidecar) and operational overhead running the control plane.

For the entry-point layer above the mesh, see API Gateway Architecture. For the resilience pattern the sidecar enforces, see Circuit Breaker Architecture. Service discovery within the mesh is covered in Service Discovery Flow.

Frequently asked questions

A service mesh is a dedicated infrastructure layer that intercepts all service-to-service network traffic through sidecar proxies, providing traffic management, mutual TLS encryption, retries, circuit breaking, and observability without requiring changes to application code.

Each microservice is deployed alongside a sidecar proxy (typically Envoy). All outbound and inbound traffic flows through the sidecar rather than directly between applications. A centralized control plane (Istio, Linkerd, Consul) pushes routing rules, security policies, and telemetry configuration to every sidecar, and collects metrics and traces from them.

Use a service mesh when you have a large number of microservices across multiple teams and need consistent enforcement of security (mTLS), observability (distributed traces), and resilience policies (retries, timeouts, circuit breakers) without requiring each team to implement them independently in their own service.

Common mistakes include introducing a service mesh too early — before you have enough services to justify the operational overhead — underestimating the latency added by the sidecar hop, and not tuning the control plane for large clusters, which can cause configuration propagation delays at scale.

mermaid

flowchart TD
    subgraph ControlPlane[Control Plane]
        CP[Mesh Control Plane\nIstio / Linkerd / Consul]
        OB[Observability Backend\nMetrics / Traces / Logs]
    end

    subgraph DataPlane[Data Plane]
        SPA[Sidecar Proxy A\nEnvoy] --- SvcA[Service A]
        SPB[Sidecar Proxy B\nEnvoy] --- SvcB[Service B]
        SPC[Sidecar Proxy C\nEnvoy] --- SvcC[Service C]
    end

    CP -->|Push policy & config| SPA
    CP -->|Push policy & config| SPB
    CP -->|Push policy & config| SPC
    SPA -->|mTLS traffic| SPB
    SPB -->|mTLS traffic| SPC
    SPA -->|Telemetry| OB
    SPB -->|Telemetry| OB
    SPC -->|Telemetry| OB