We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Microservices Architecture
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Microservices Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A motorcycle sidecar doesn't change the motorcycle. It doesn't modify the engine, the handlebars, or the braking system. It attaches alongside the motorcycle and adds a capability, carrying an extra passenger, without altering the core vehicle.
In , a sidecar container works the same way. Your application container runs its business logic, unchanged. A sidecar container runs alongside it in the same pod, sharing the network and storage, adding cross-cutting capabilities like logging, monitoring, encryption, or configuration management.
The key insight: your application doesn't know the sidecar exists. It writes logs to stdout, and the sidecar ships them to Elasticsearch. It makes calls to localhost:9090, and the sidecar handles mTLS and routing. The application stays simple and focused on business logic. The sidecar handles infrastructure concerns.
This is the pattern behind Istio's Envoy proxy, Fluentd log collectors, Vault agent for secret management, and dozens of other infrastructure tools. Lyft originally built Envoy specifically because they needed a language-agnostic way to add consistent networking behavior across their polyglot service fleet. Every service, regardless of language, got the same retry logic, circuit breaking, and observability by running Envoy as a sidecar.
A sidecar container runs in the same pod as the application container. Being in the same pod means they share:
| Shared Resource | What It Enables |
|---|---|
| Network namespace | Sidecar listens on localhost; app calls localhost, no network hop |
| Storage volumes | App writes logs to a shared volume; sidecar reads and ships them |
| Lifecycle | Sidecar starts and stops with the app container |
Common sidecar use cases:
| Sidecar | What It Does | Example | Resource Cost |
|---|---|---|---|
| Log shipper | Collects logs from the app and sends them to a centralized system | Fluentd, Filebeat, Vector | 30-80MB RAM |
| Handles mTLS, retries, circuit breaking for all traffic | Envoy (Istio), linkerd2-proxy | 50-100MB RAM | |
| Secret manager | Injects secrets into the app's environment or filesystem | Vault Agent | 20-40MB RAM |
| Config reloader | Watches for configuration changes and signals the app to reload | ConfigMap watcher | 10-20MB RAM |
| Metrics exporter | Scrapes app metrics and exposes them in format | StatsD exporter | 20-50MB RAM |
Kubernetes 1.28 introduced native sidecar container support with restartPolicy: Always in init containers. Before this, sidecars were just regular containers in the pod spec with no ordering guarantees. The native sidecar feature ensures the sidecar starts before the app and stops after it, solving the long-standing startup ordering problem.