Distributed Application Architecture Patterns

5.1 Sidecar

This pattern is based on Sidecar defined by Burns [65, later 22, p. 11]. It was originally defined specifically for implementation with containers but has since become a general term for any process or container running alongside a main service; see Richardson [20, p. 410, 66] and Microsoft [67].

5.1.1 Context

Multiple services are created with different, incompatible technologies and need to share some functionality. Alternatively, the services might need to offload some functionality so that it does not affect them, but it is still advantageous to have it close by.

5.1.2 Solution

Implement a small, locally running Sidecar service that provides the necessary functionality (see fig. 6). This service communicates with the main service over the network and can be deployed with multiple other services. Since the sidecar is running on the same node, it has access to all of the same local resources as the main service.

This relationship does not necessarily have to be one-to-one¹. Depending on the need, multiple services can attach to one sidecar, and one service can have multiple sidecars attached to it.

5.1.3 Potential issues

Compared to a shared library, a sidecar will still add unnecessary overhead and latency, even though it is running nearby. Since it lives separately from the main service, it also adds additional complexity to the system. Furthermore, if the sidecar fails, it can affect the main service, and debugging across service boundaries can be more challenging.

Depending on the type of functionality the sidecar provides, it can also lead to tight coupling between the service and the sidecar, potentially leading to the sidecar becoming a development bottleneck.

Since a sidecar runs on the same node as the main service, it can be difficult to scale. If the sidecar needs to handle disproportionately more work than the main service, consider offloading the functionality to a separate service instead.

5.1.4 Example

ExampleEshop needs to process product images, but it also allows users to post images in their product reviews. These functionalities are handled by different services using different technologies. These need to be converted into different formats and sizes, such as thumbnails or lower-resolution images for mobile devices. To reduce code duplication, the image processing is handled by a sidecar service deployed alongside both services. This has the added benefit of allowing more fine-grained control over the resource usage of the image processing and isolating any potential failures from the main services.

5.1.5 Related patterns

This pattern expands upon the idea of the Colocate pattern. The following patterns are commonly deployed as sidecars to improve performance.

1. Ambassador, for placing helper services between clients and main services (see § <>)

2. Anti-Corruption Layer, for abstracting different domains

Health Monitoring can be beneficial to implement as a sidecar due to its close access.