A sidecar is a companion process deployed beside an application in the same scheduling unit — pod, VM, or host — sharing its network and storage. It adds or adapts capabilities — TLS termination, retries, protocol translation, telemetry — while the application stays unchanged.

Burns and Oppenheimer named the pattern in 2016: containers had made co-deployment cheap enough to turn “modify the application” problems into “deploy a companion” problems. Most service meshes build on it, though sidecar-less variants are emerging.

Sidecar: a companion process in the same scheduling unit intercepts inbound traffic, hands it to the unchanged application over localhost, proxies outbound calls, and ships telemetry.

How It Works

  • Sidecar and application share fate: they scale, schedule, and die together.
  • The shared network namespace lets the sidecar intercept inbound or outbound traffic transparently via localhost or port redirection.
  • The sidecar ships and upgrades on its own cadence, independent of the application’s release cycle.
  • One sidecar image serves every language in the fleet — the capability is written once, not once per stack.

Failure Modes

  • The application starts before the sidecar is ready, or the sidecar drains first at shutdown; calls fail at every rollout.
  • The sidecar accretes features until every release of it risks the whole fleet at once.
  • Overhead surfaces at scale: thousands of instances each reserve sidecar CPU and memory; the infrastructure bill jumps.
  • A crashing or saturated sidecar takes its healthy application down — shared fate cuts both ways.

Verification

  • Sidecar CPU and memory stay within an agreed per-instance budget, e.g. below 10% of the workload’s reservation.
  • p95/p99 latency with and without interception stays within the agreed delta.
  • Chaos check: killing the sidecar marks the whole instance unhealthy and traffic shifts away; no half-alive instance keeps serving.
  • Rollout logs show sidecar upgrades completing fleet-wide with zero application code changes.
  • Ambassador: a sidecar proxying the application’s outbound calls — discovery, routing, retries — so the application sees only localhost.
  • Adapter: a sidecar normalizing the application’s output — metrics, logs — to a fleet-wide standard.
  • Service mesh: sidecars at fleet scale under central control; sidecar-less designs (ambient, eBPF) move the proxy to node level to cut overhead.

References