Service Mesh — Simple

flowchart LR
  subgraph PodA[Pod A]
    A[Service A]
    SA([Sidecar proxy])
  end
  subgraph PodB[Pod B]
    SB([Sidecar proxy])
    B[Service B]
  end
  CP([Control plane])
  A --> SA -- mTLS, retries, traces --> SB --> B
  CP -.config.-> SA
  CP -.config.-> SB

    classDef client fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
    classDef edge fill:#cffafe,stroke:#0e7490,stroke-width:1px,color:#0f172a;
    classDef service fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
    classDef datastore fill:#fee2e2,stroke:#991b1b,stroke-width:1px,color:#0f172a;
    classDef cache fill:#fed7aa,stroke:#9a3412,stroke-width:1px,color:#0f172a;
    classDef queue fill:#ede9fe,stroke:#5b21b6,stroke-width:1px,color:#0f172a;
    classDef compute fill:#d1fae5,stroke:#065f46,stroke-width:1px,color:#0f172a;
    classDef storage fill:#e5e7eb,stroke:#374151,stroke-width:1px,color:#0f172a;
    classDef external fill:#fce7f3,stroke:#9d174d,stroke-width:1px,color:#0f172a;
    classDef obs fill:#f3e8ff,stroke:#6b21a8,stroke-width:1px,color:#0f172a;
    class A,SA,SB,B,CP service;

A service mesh adds a sidecar proxy next to every pod. Apps speak plain HTTP/gRPC to localhost; the sidecar handles mTLS, retries, traffic splitting, observability, and authz without any app changes.