Module 12 · Microservices patterns · Lesson 4 of 8
Sidecar
A helper process deployed next to each service instance that provides networking, security, observability or configuration without changing the application. Why co-location rather than a library, what typically rides in a sidecar.
Why it matters
Every service needs the same things: TLS to its peers, retries and timeouts, metrics, log shipping, secrets, configuration refresh. Implementing them as a library in every language the organisation uses means five implementations that drift and a coordinated upgrade whenever one changes. The sidecar pattern moves those concerns into a separate process that runs beside each instance, so the application stays focused and the platform team owns the shared behaviour. It is the mechanism underneath service meshes and much of modern platform engineering.
The idea
A sidecar is a secondary process deployed in the same unit as the application (the same Kubernetes pod, the same VM) sharing its network namespace and lifecycle. The application talks to the sidecar over localhost, or the sidecar transparently intercepts the application's traffic, and the sidecar handles the cross-cutting concern. Because it is a separate process, it can be written once in one language, upgraded independently, and attached to any service regardless of the service's language or framework.
What rides in a sidecar
| Concern | Sidecar role | Example |
|---|---|---|
| Service-to-service networking | Discovery, load balancing, retries, timeouts, circuit breaking on behalf of the app | Envoy, Linkerd proxy |
| Security | Mutual TLS with automatic certificate rotation; authorization policy between services | Istio, Consul Connect, SPIFFE identities |
| Observability | Uniform metrics, access logs and trace spans for every request without app code | Mesh telemetry, OpenTelemetry collector sidecars |
| Log and metric shipping | Tail the app's logs and forward them | Fluent Bit, Vector |
| Configuration and secrets | Fetch and refresh config and secrets, present them to the app as files or a local endpoint | Vault agent, config reloaders |
| Protocol adaptation | Expose a legacy or foreign protocol as something the app understands | Ambassador and adapter variants |
The ambassador variant is a sidecar that proxies outbound calls to external systems (handling auth, retries and rate limits for a third-party API); the adapter variant normalises the application's output (metrics, logs) into a standard format.
Why not a library
A library is in-process and faster, and for a single-language organisation with a mature shared library it is a fine choice. Sidecars win when the organisation is polyglot, when the platform team must upgrade behaviour without waiting for every service to rebuild, when the concern involves network interception (mTLS) that is awkward in-process, and when uniform telemetry across services matters more than a millisecond.
Costs
Each sidecar consumes memory and CPU (tens to hundreds of megabytes and a fraction of a core per instance), which multiplied across thousands of pods is a real bill. It adds a hop on localhost, typically well under a millisecond but visible at the tail. It complicates the pod lifecycle: the sidecar must start before the app and stop after it, which orchestrators now support natively. Debugging gains a layer. Sidecarless meshes (Istio ambient mode, eBPF-based approaches) move the proxy to a per-node agent to reclaim those resources, trading per-pod isolation for efficiency.
Where it leads
Deploying the same sidecar beside every service and controlling them from a central control plane is a service mesh, the last lesson of this module. The sidecar is the data plane; the control plane distributes configuration, certificates and policy. Understanding the sidecar as a pattern first makes the mesh an obvious consequence rather than a mystery.