sidecar.
three.js + anime.js

System design, animated

The Sidecar Pattern

Give every service logging, security, and traffic control without touching a single line of its code.

Follow the packet

02 The pattern

A helper that rides along

A sidecar is a second process that runs next to your application and handles the chores: proxying traffic, terminating TLS, shipping logs, reporting metrics.

It lives in the same pod, shares the same life cycle, and never asks the application to change. Your service keeps serving. The sidecar deals with the rest.

The name comes from motorcycles. The sidecar carries the luggage; the bike stays a bike.

  • Same pod, same life cycle
  • Its own process and resources
  • Upgraded without redeploying the app

03 Inside the pod

Close enough to share

Containers in a pod share a network namespace and can share volumes. That closeness is what makes the pattern cheap.

Loopback networking

Both containers talk over localhost. The sidecar intercepts traffic without crossing the network.

Shared volumes

Log files, sockets, and configs pass through a volume that both containers can read and write.

One life cycle

They start, stop, and scale as a single unit. The scheduler treats the pod as the atom. 

apiVersion: v1kind: Podspec:  containers:    - name: app        # your service      image: acme/api:1.4    - name: sidecar    # rides along      image: envoyproxy/envoy:v1.31

04 The flow

Every request passes through

Watch one request make the trip. The client never talks to the app directly, and the app only ever sees clean local traffic.

  1. 1

    The client connects

    The request arrives at the pod, not at the application.

  2. 2

    The sidecar intercepts

    TLS terminated, identity verified, policy checked, retries armed.

  3. 3

    Forward over localhost

    The request hops to the app inside the pod network namespace.

  4. 4

    The response returns

    The sidecar observes, meters, and encrypts the trip back.

05 Offloaded work

Chores the app should not do

If every service needs it, and it is not the service's job, it belongs in a sidecar.

Observability

Logs, metrics, and traces leave through one door, in one format.

Security

mTLS, token exchange, and certificate rotation, away from app code.

Traffic control

Retries, timeouts, circuit breaking, and rate limits per route.

Discovery

Service lookup and health checks, so callers find healthy pods only.

Configuration

Feature flags and secrets refreshed without restarting the app.

Translation

gRPC to HTTP, JSON to protobuf, old protocol to new.

The app rests while the sidecar works. That division of labor is the whole idea.

06 Trade-offs

Worth the weight?

A sidecar costs resources and adds a hop to every call. It pays for itself when a concern is universal and untouchable.

It earns its seat

  • No application code changes
  • Works for any language or framework
  • Update policy without redeploying the app
  • One consistent behavior across every service

It adds weight

  • Extra CPU and memory for every pod
  • One more network hop per request
  • More processes to operate and observe
  • Startup and shutdown ordering gets tricky

Seen in the wild

  • Envoy
  • Istio
  • Linkerd
  • Dapr
  • Fluent Bit
  • Vault Agent

Use a sidecar when a concern applies to every service and belongs to none of them.