# Sidecar Pattern

URL: https://softwaredictionary.org/terms/sidecar-pattern
Category: Software Architecture
Last updated: 2026-10-05
In Turkish: Sidecar Deseni
Pronunciation: SYDE-kar

In short: The sidecar pattern runs a helper process next to an application, sharing its lifecycle and network, to add features such as logging, proxying or security.

## What is the sidecar pattern?

A sidecar is a separate process or container deployed alongside the main application, like a sidecar attached to a motorcycle: it goes wherever the application goes, starts and stops with it, and shares its network and storage. The application does its own job, and the sidecar handles a supporting one, such as shipping logs, renewing certificates, collecting metrics or proxying traffic.

The benefit is separation. A supporting feature lives in its own code, in its own language and with its own releases, and the same sidecar can serve applications written in Java, Go or Python without changing them. Service meshes are built on this idea: each service gets a proxy sidecar, such as Envoy, that handles encryption, retries and routing for every call, so the application code doesn't have to.

In Kubernetes, a sidecar is another container in the same pod, so it shares the pod's network and can share its volumes. Kubernetes added native sidecar containers in version 1.28 and made them stable in 1.33: an init container with `restartPolicy: Always` starts before the application and keeps running beside it. The cost is resources and complexity, since every instance carries an extra process, which is why some service meshes now offer one shared proxy per node instead.

## Key takeaways

- A sidecar is a helper process deployed next to an application, sharing its lifecycle.
- It adds supporting features, such as logging or proxying, without changing the application.
- In Kubernetes, a sidecar is another container in the same pod.
- Service meshes put a proxy sidecar beside every service.

## Example: A log-shipping sidecar in a Kubernetes pod

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  initContainers:
    - name: log-shipper         # the sidecar: starts first, then runs alongside
      image: example/log-shipper:1.0
      restartPolicy: Always
      volumeMounts:
        - { name: logs, mountPath: /var/log/app }
  containers:
    - name: app                 # the application writes logs, the sidecar ships them
      image: example/web:1.4
      volumeMounts:
        - { name: logs, mountPath: /var/log/app }
  volumes:
    - name: logs
      emptyDir: {}
```

## Frequently asked questions

**What is the difference between a sidecar and a library?**

A library runs inside the application's process and has to exist for its language. A sidecar runs as a separate process, so it works with any language and can be updated on its own, at the cost of an extra process and an extra hop on the network.

**Do sidecars slow requests down?**

A proxy sidecar adds a short hop on the same machine, usually a fraction of a millisecond, and uses some memory and CPU in every instance. For most services that is a fair price for what it handles, but across thousands of instances the total cost adds up.

## Sources

- [Azure Architecture Center: Sidecar pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/sidecar)
- [Kubernetes documentation: Sidecar Containers](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/)

---

Software Dictionary: https://softwaredictionary.org/ · https://softwaredictionary.org/llms.txt