PATTERN Cited by 1 source
Sidecar agent¶
Run a small helper process in the same pod / network namespace as the main service, handling a cross-cutting concern (config fetch, service-mesh proxy, log shipping, secret rotation, telemetry) so the application stays thin and language-agnostic. Canonical shapes: Envoy in a service mesh, Fluent Bit for logs, a config-fetcher for feature flags.
Why the sidecar shape¶
- Language-agnostic. One sidecar binary serves every language runtime; the client-side library in each language only needs to read a local file or socket.
- Failure isolation. Sidecar crash doesn't crash the application (it just has to tolerate stale data).
- Local cache for resilience. The sidecar persists state to a local path; when the backend is unavailable, the application reads last-known-good state and keeps running.
- Network-local reads. No cross-node round trip for every config or flag lookup — reads are local filesystem or localhost.
Tradeoffs¶
- Extra memory + CPU per pod.
- Extra deployment surface (sidecar versioning, rollout).
- Startup ordering (app must wait for sidecar to warm cache on cold start).
Seen in¶
- sources/2026-02-18-airbnb-sitar-dynamic-configuration — Airbnb Sitar runs a config-fetching sidecar beside every service container. It pulls subscribed configs from the Sitar data plane, persists them to a local cache, and in-process client libraries read that cache. Services survive data-plane outages on last-known-good configs.