Summary
The Sidecar pattern deploys application components into a separate process or container to provide isolation and encapsulation. The name comes from the sidecar attached to a motorcycle. The sidecar is attached to the parent application, provides supporting features, and shares the same lifecycle as that application. Peripheral tasks such as monitoring, logging, configuration, and network services sit outside the main application, and the sidecar can be written in a different language. The two processes communicate over local HTTP, gRPC, or Unix sockets.
Key Points
- Purpose: Separate peripheral tasks (monitoring, logging, configuration, network services) from the main application to avoid tight coupling and increase technology flexibility.
- Benefits:
- Language independence: The sidecar can be written in a different language from the main application.
- Resource proximity: The sidecar can access the same system resources as the main application without significant network latency.
- Fault isolation: A failure in the sidecar is less likely to bring down the entire main application, and vice versa.
- Lifecycle management: The sidecar is deployed and retired together with the main application.
- How it works: Each instance of the main application has an accompanying sidecar instance. They communicate through inter-process communication (IPC) mechanisms such as local HTTP, gRPC, or Unix sockets.
- Considerations:
- Resource overhead: Running a separate process/container for each instance can be resource-expensive for small applications.
- Communication latency: Even though they are close, inter-process communication still has some latency compared with an in-process function call.
- Deployment complexity: Requires an orchestration mechanism (such as Kubernetes) to manage the application-sidecar pair.
When to Use
- When the application uses many different languages and frameworks (heterogeneous).
- When a component is owned by a remote team or another organization.
- When you need fine-grained control over resource limits (CPU, memory) for each supporting component separately.
- When you want to extend the functionality of legacy applications that have no extensibility mechanism.
Examples
- Infrastructure API: A sidecar that provides a common access layer for logging, health checks, and fetching configuration.
- Ambassador sidecar: Handles routing, circuit breaking, and logging for outbound requests.
- Offload proxy: Uses an NGINX sidecar to serve static content in front of a Node.js service.
Relationships
- Ambassador Pattern: A variant of Sidecar that focuses on connecting to external services on behalf of the application.
References
See also: Ambassador Pattern · Gateway Offloading Pattern · Anti Corruption Layer Pattern