A sidecar is a helper process deployed alongside your main application — same host, same lifecycle, separate binary. It handles cross-cutting concerns (TLS, auth, metrics, log shipping, config reload) so your application code doesn't have to. Think of it like a motorcycle sidecar: it travels with the bike, shares the ride, but has its own seat.

The classic example is Envoy as a service mesh sidecar (Istio, Linkerd, Consul Connect). Your Go service talks plain HTTP to localhost:8080. Envoy, running in the same Kubernetes pod, intercepts that traffic and adds mTLS, retries, circuit breaking, traffic splitting for canaries, and detailed metrics. Your application code knows nothing about any of it. Want to rotate certificates? Update Envoy. Want to add tracing headers? Update Envoy. The service code stays focused on business logic.

Other real sidecars you've probably touched:

• Fluent Bit — tails your app's stdout and ships logs to Elasticsearch or Loki.
• Vault Agent — fetches secrets, renews leases, writes them to a shared volume your app reads.
• cloud-sql-proxy — provides a local socket your app connects to; handles IAM auth and TLS to Cloud SQL.
• OpenTelemetry Collector — receives spans on localhost, batches and exports them.

Why this beats a library: libraries force every service (in every language) to upgrade in lockstep. A sidecar upgrades independently — restart the sidecar container, leave the app alone. Polyglot shops win the most: one Envoy sidecar gives mTLS to your Go, Python, Ruby, and Rust services without writing four TLS integrations.

The cost — a rule of thumb: each sidecar adds roughly 50–150 MB of memory and a few millicores of CPU per pod. At 1,000 pods, an Envoy sidecar costs you ~100 GB of RAM cluster-wide. That's real money. If you have 10 services, fine. If you have 3 services and a small cluster, a library is cheaper.

When NOT to use a sidecar:

• You need sub-millisecond latency — the extra localhost hop adds 0.1–1 ms.
• You have a monolith — there's no "alongside," just put it in the process.
• The concern is intrinsic to your domain logic (validation, business rules). Sidecars are for infrastructure concerns.

Operationally, treat the sidecar as part of the pod's contract: shared lifecycle, shared failure domain. If the sidecar crashes, the pod is unhealthy. Use Kubernetes initContainers or sidecarContainers (native sidecars, GA in 1.29) so startup ordering is deterministic.