Intermediate12 min

Sidecar

Deploy cross-cutting concerns beside a service instead of inside it.

By the end of this lesson, decide what belongs in a sidecar versus the application itself.

How deep?

How the pieces actually move.

A sidecar is a helper process deployed alongside your service (same pod/host) that handles cross-cutting concerns — mTLS, retries, routing, metrics, secrets — so your application code doesn't have to. The service mesh data plane (e.g., Envoy) is the best-known example: every service gets a proxy sidecar.

First, the whole system

First, see the whole system. Then we’ll open it up.

App + sidecar per instance

Each pod runs the app plus a sidecar proxy; the app talks to the sidecar, which handles mTLS, retries, and metrics on the network.

flowchart LR
  subgraph pod [Pod]
    app[App container]
    side[Sidecar proxy]
  end
  app <--> side
  side <-->|mTLS, retries, metrics| net[Network / other sidecars]

The win is language-agnostic, uniform infrastructure behavior: policy, security, and observability are enforced identically for services written in any language, upgraded centrally without touching app code. The cost is one extra process per instance — memory, latency (an extra hop), and operational surface.

Operational complexity

Sidecars centralize cross-cutting behavior and keep apps simple, but multiply process count and add a per-call hop and resource overhead. At small scale that overhead may not be worth it; at fleet scale, uniformity wins.

How it connects

Why put mTLS and retries in a sidecar instead of each service?

So the behavior is uniform and language-agnostic across all services and can be upgraded centrally without changing application code.