Part 0 · 2 chapters · ~12 min

The Sidecar Pattern and Why It Exists

The cross-cutting problems every service has, the library era and its per-language cost, the sidecar as a separate process in the same pod, traffic interception with iptables and eBPF, mutual TLS with workload identity, uniform telemetry, and what a sidecar cannot see.

1

From libraries to sidecars

Netflix solved service-to-service problems with Java libraries (Hystrix, Ribbon, Eureka). That works when every service is Java. In a company with Node, Go, Python and Java services, every resilience and security feature must be reimplemented and kept consistent in every language. A sidecar runs the same proxy beside every service, so the behaviour is identical everywhere and upgrades happen without touching application code.

concernin a libraryin a sidecar
mTLSTLS config and cert rotation in each appautomatic, rotated by the control plane
retries, timeoutsper-language libraries, inconsistent defaultsone policy object per route
traffic splittingcustom code or a gatewayweights in config
telemetryinstrument every serviceuniform proxy metrics
business contextavailable (user, tenant, operation)invisible: the proxy sees bytes and headers only
THE SIDECAR PATTERN
a proxy in the same pod intercepts every connection in and out
localhostmTLSlocalhostapp Aplain HTTP to localhostproxy AEnvoy sidecarproxy BEnvoy sidecarapp Breceives plain HTTPcontrol planeconfig, certs, endpoints
swipe the figure sideways, or tap expand for full screen
1/6
interception
An init container installs iptables rules (or eBPF programs) so all traffic leaving and entering the pod is redirected to the sidecar proxy. The app still thinks it is calling ledger:8080 directly.
iptables or eBPF redirect traffic to the proxythe application code does not change
2

What a sidecar cannot do

still the application's job
  1. Propagate trace headers from incoming to outgoing requests (the proxy cannot know which outgoing call belongs to which incoming one).
  2. Idempotency: a proxy retry of a non-idempotent POST can double a payment; only the app knows what is safe to retry.
  3. Business authorisation: "may user 7 read account 9?" needs domain data.
  4. Graceful degradation: what to show when a dependency is down is a product decision.
  5. Startup ordering: the app must tolerate the sidecar not being ready yet (or use native sidecar containers in recent Kubernetes).