Sidecar Process
A sidecar process is a small helper program that runs directly alongside a main program, taking on tasks such as encryption, logging, or metrics on its behalf. This keeps the main program lean, since it doesn't have to handle this extra work itself.
Large internet services today consist of many small programs that work together. Each of these programs has a clear task, such as accepting orders or calculating prices. But alongside this, the same extra work always crops up: securing connections, logging errors, collecting metrics. A sidecar process is a second, small program that takes on exactly this extra work. It runs directly next to the actual program on the same machine and shares network and storage with it. The name comes from a motorcycle sidecar: a separate seating unit, but firmly mounted to the vehicle and always traveling the same route.
Why companies outsource extra work
Without a sidecar, every single program would have to handle the extra work itself. With twenty programs, that means the same code twenty times over. If a security rule changes, a team has to touch and redeploy twenty programs. With a sidecar, you only change the sidecar instead. The actual programs remain untouched.
A second advantage is independence from the programming language. In a large company, one service might be written in Java, the next in Python, the third in Go. A sidecar only talks to them over the network. That’s why the same sidecar works for all three, regardless of which language they’re written in.
The price for this is overhead. Every sidecar needs memory and processing time, and with a thousand services, a thousand sidecars run alongside them. Additionally, every detour through the sidecar costs a few milliseconds. Companies therefore weigh which tasks are truly worth the detour.
The detour through the sidecar
Technically, the sidecar sits between the main program and the outside world. Everything the main program sends out goes to the sidecar first. It encrypts the data, records the transaction, and forwards it. Incoming requests travel the same path in reverse. The main program notices none of this; it believes it’s talking directly to the destination.
This is made possible by the shared environment. Both processes run within the same isolated unit, which in the Kubernetes system is called a pod. There, they share the network address and often also a storage folder for files. A sidecar can, for example, read along in the main program’s log file and send its contents to a central collection service.
It’s important to distinguish this from a library. A library is finished code that you build into your own program, so it runs with it in the same process. The sidecar is an independent process with its own memory. If it crashes, the main program often keeps running, but loses its extra functions. A common misconception is that sidecars are always containers: that’s the usual case, but not a requirement.
Sidecars in data centers and AI services
The pattern is best known in so-called service meshes, i.e., systems that manage traffic between many services. Well-known examples are Istio and Linkerd. They place a network sidecar next to each service, usually the software Envoy. It handles encryption, load balancing, and retries on errors.
The pattern also appears in AI applications. Alongside a model server, there’s often a sidecar that counts every request and attributes the costs to the right customer. Other sidecars check inputs for prohibited content before they reach the model. Such filters are called guardrails.
In tech news, you currently encounter the term mainly in one debate. Because sidecars consume a lot of memory, developers are working on sidecar-less alternatives that handle the same tasks deeper within the operating system. If you follow the discussion, you’ll see a typical pattern in the industry there: a concept becomes established, becomes the standard, and is then called into question again because of its costs.