We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Microservices Architecture
A helper container deployed alongside the main application container in the same pod. Handles cross-cutting concerns like logging, monitoring, or TLS without modifying app code.
In short
A sidecar is a helper process deployed right next to a main application, usually as a second container in the same Kubernetes pod, that handles supporting work like TLS encryption, traffic routing, logging, and metrics so the application code does not have to. The two share the same network and local storage, so the sidecar can intercept the app's traffic and read its files without any code changes to the app itself.
In short
A sidecar is a helper process deployed right next to a main application, usually as a second container in the same Kubernetes pod, that handles supporting work like TLS encryption, traffic routing, logging, and metrics so the application code does not have to. The two share the same network and local storage, so the sidecar can intercept the app's traffic and read its files without any code changes to the app itself.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Sidecar across a run of lessons, not one page. These 4 alone are about 79 minutes of step-by-step reading, every one with a quiz.
Attach a helper container to your application, handling logging, monitoring, proxying, or configuration without modifying the app.
A specialized sidecar that handles outbound connectivity, connection pooling, retries, and protocol translation for external services.
Running setup tasks before the main container starts: migrations, config fetching, dependency checks.
Running two versions at once, everything they have to share, and why the weight change is the easiest part of it.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Sidecar Container Patternpay once,
yours for life
The name comes from the small passenger car bolted onto the side of a motorcycle. The motorcycle does the driving; the sidecar comes along and adds capacity. In software, the motorcycle is your application and the sidecar is a separate process that rides along to handle the boring but necessary jobs every service needs.
Concretely, on Kubernetes a sidecar is a second container in the same pod as your app container. Because containers in a pod share a network namespace and can share volumes, the sidecar reaches the app over localhost (127.0.0.1) and can mount the same directory the app writes logs to. The app keeps doing one thing; the sidecar does the cross-cutting thing.
The whole point is separation. Your team writes business logic. A platform team ships a sidecar image that does mTLS, retries, rate limiting, or log shipping. You get those features by adding a container to your pod spec, not by importing a library into every service in every language you run.
The most common job is networking. A proxy sidecar like Envoy uses an init container to rewrite the pod's iptables rules so that all inbound and outbound TCP traffic is redirected to the proxy first. The app thinks it is talking directly to another service, but every packet actually flows through the sidecar, which can add TLS, record latency, retry failed calls, or shed load. This is exactly how a service mesh data plane works.
Other sidecars are simpler. A logging sidecar tails a shared log file and forwards lines to Elasticsearch or Loki. A secrets sidecar fetches credentials from Vault and writes them to a shared in-memory volume the app reads. A config sidecar watches for changes and signals the app to reload. None of them require the app to know they exist.
Lifecycle matters. A plain extra container starts and stops in no guaranteed order, which breaks startup if the app needs the proxy ready first. Kubernetes 1.28 introduced native sidecar support (off by default until 1.29, stable in 1.33): you mark the container as a restartable init container and it starts before app containers and shuts down after them, fixing the long-standing race conditions.
Reach for a sidecar when you need the same capability across many services written in different languages and you do not want to maintain a client library for each one. mTLS between every service, uniform request metrics, and centrally controlled traffic policy are textbook cases. It is also the cleanest way to add behavior to a third-party or legacy app you cannot recompile.
The cost is real. Every pod now runs an extra container, so you double your container count and pay for its CPU and memory. A mesh of Envoy sidecars across thousands of pods can add meaningful overhead and a few milliseconds of latency per hop. There is also operational weight: another image to patch, version, and roll out, plus the iptables magic makes debugging harder when something goes wrong.
The main alternatives are a shared library baked into the app (no extra process, but you must build and update it for every language) and, more recently, eBPF-based meshes like Cilium that move proxy work into the kernel to avoid the per-pod sidecar entirely. Pick a sidecar when uniformity across languages beats raw efficiency.
Take Istio, the most widely deployed service mesh. When you label a namespace for injection, Istio automatically adds an Envoy sidecar to every pod. Say your checkout service calls your payment service. The checkout app sends a plain HTTP request to the payment hostname. Its Envoy sidecar intercepts that request, opens a mutually authenticated TLS connection to the payment pod's Envoy, and that proxy hands the decrypted request to the payment app over localhost.
Neither application wrote a line of TLS code. The platform team set a policy saying all traffic must be encrypted, and Istio's control plane pushed that config to every sidecar. The same sidecars also export request counts and p99 latency to Prometheus, so you get a service dependency graph and golden metrics for free.
If the payment service starts failing, an operator can tell the sidecars to retry twice and trip a circuit breaker after five errors, again without touching application code or redeploying the apps. That decoupling of operational concerns from business logic is why the pattern spread across the industry.
Istio
Injects an Envoy sidecar into every pod to provide mTLS, traffic routing, retries, and metrics as a service mesh.
Linkerd
Runs a lightweight Rust micro-proxy sidecar per pod for transparent mTLS and latency-aware load balancing.
AWS App Mesh
Deploys an Envoy sidecar alongside ECS and EKS workloads to standardize service-to-service communication and observability.
HashiCorp Vault
Ships a Vault Agent sidecar that fetches and renews secrets, then writes them to a shared volume the app reads with no SDK.
A sidecar is the building block; a service mesh is the whole system. The mesh is the sidecar proxies on every pod (the data plane) plus a central control plane that configures them. You can run a single sidecar without a mesh, but a mesh is just many sidecars managed together.
No. On Kubernetes a sidecar runs as an additional container inside the same pod as the application. That co-location is what lets it share localhost networking and mounted volumes with the app, which is the entire reason the pattern works.
You double the number of running containers, which costs extra CPU and memory and adds a few milliseconds of latency when a proxy sits in the request path. You also take on more operational work patching and upgrading the sidecar image across every pod.
The big ones are a network proxy (Envoy for mTLS, retries, and routing), a logging agent that ships a shared log file to a backend, a secrets agent that pulls credentials from Vault, and a metrics or config-reload helper. Anything cross-cutting that every service needs is a candidate.
An init container runs to completion before the app starts and then exits, used for setup like running migrations. A sidecar runs for the entire life of the app alongside it. Kubernetes 1.28 blurred the line by letting you define a sidecar as a restartable init container so it starts first but keeps running.
Service Mesh
A dedicated infrastructure layer for handling service-to-service communication in microservices. Manages load balancing, encryption, and observability automatically.
Kubernetes
An orchestration platform that automates deploying, scaling, and managing containerized applications. K8s is the operating system for your cloud.
Docker
A platform for packaging applications into lightweight, portable containers. 'Works on my machine' becomes 'works everywhere.'
Microservices
An architecture where an application is split into small, independent services that communicate over the network. Each service owns its own data and can be deployed separately.
Monolith
A single, unified application where all features share the same codebase and deployment. Simpler to start with but harder to scale individual parts.
Service Discovery
The mechanism by which microservices find and communicate with each other. Services register themselves and others can look them up by name.
This page explains the idea. The "Sidecar Container Pattern" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Sidecar Container Pattern lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Sidecar in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
