Sidecar
Attach cross-cutting concerns as a co-located helper process.
IntermediatePlatform
A helper process deployed alongside the main service handles concerns like proxying, logging or config -- without the main service's code needing to implement or even know about them.
When to use it
- Cross-cutting infrastructure logic (mTLS, metrics, config reload) shouldn't live in every service's codebase
- Multiple services in different languages need the same platform capability applied consistently
Trade-offs
- Adds a second process per instance to deploy, version and monitor
- Local network hop between service and sidecar adds a small latency cost
Components used
Container ServiceService MeshManaged App Service
How it works
- A helper process runs alongside the application in the same deployment unit, sharing its lifecycle and network namespace.
- Cross-cutting concerns — TLS, telemetry, config reloading, log shipping — move into the sidecar, out of the application.
- The application can be written in any language and still gain those capabilities, since the sidecar is a separate process rather than a library.
Used in the wild
- Polyglot environments where maintaining an observability library per language is impractical.
- Adding mutual TLS to services that have no idea it is happening.
- Log and metric collection agents co-located with each workload.
Good to know
- Named after motorcycle sidecars — attached to the main vehicle, sharing its journey, but structurally separate.
- Every sidecar multiplies resource overhead by the number of pods, which at thousands of instances becomes a genuine line item. This drove interest in ambient and per-node alternatives.
Related patterns
Model Serving with A/B Testing
Route inference traffic across model versions to compare live performance.
CQRS
Separate models and stores for writes and reads.
Blue-Green Deployment
Run two full production environments, switch traffic between them.
Canary Release
Send a small slice of traffic to the new version before a full rollout.