What is the Sidecar pattern?
A sidecar is a separate container or process deployed with the service and sharing its lifecycle and network. It handles concerns such as mutual TLS, service discovery, retries, metrics and configuration. A service mesh is a fleet of sidecar proxies, such as Envoy, managed by a control plane.
What problem does the Sidecar pattern solve?
Resilience, security and telemetry are needed in every service, in every language. Implementing them in each codebase leads to drift and inconsistency. A sidecar provides them uniformly without changing the service.
How do you implement the Sidecar pattern?
- Pick a concern that is repeated everywhere, such as mTLS or telemetry.
- Deploy a proxy as a sidecar through automatic injection.
- Set policy centrally through the control plane instead of in each service.
- Measure the added latency and resource cost.
- Roll out gradually, one namespace or team at a time.
When should you use it?
- You run many services, in several languages, with a platform team to operate the mesh.
- You need consistent security and traffic policy.
When should you avoid it?
- A handful of services and a small team. A library may be simpler.
- Latency or memory budgets are tight and nobody can operate the mesh.
What do you gain?
- Uniform policy across languages
- No change to service code
- Central control of traffic and security
What does it cost?
- Resource and latency overhead
- Operational complexity
- Another layer to debug
What are common mistakes with the Sidecar pattern?
- Adopting a mesh for three services.
- Retries configured in both the mesh and the application.
- No clear owner for the mesh, so upgrades stall.
Sidecar in practice
Alder Bank
Mutual TLS, retries and load balancing lived in a shared client library. Every security fix meant upgrading and redeploying hundreds of services written in several languages.
The bank moved these concerns into Envoy sidecars managed by a mesh control plane. Policy changes now roll out centrally, at the cost of extra latency per hop and a new system to operate.
Example decision record
- Context
- Enforcing mutual TLS across services written in several languages is slowing every team down.
- Decision
- Adopt a service mesh with sidecar proxies for all workloads.
- Consequences
- mTLS is enforced between all services without code changes.
- Teams remove their own retry and TLS code, and the platform team operates the mesh.