At a glance

The sidecar pattern is a great design pattern, particularly in the realm of microservices and/or Hexagonal Architecture.
It involves attaching a companion container, the sidecar or sidekick, to the main application container in the same machine, allowing for connectivity via localhost or similar, without network calls. This is also known as co-location.

Image courtesy of eraser.io

This auxiliary container encapsulates additional functionalities, such as logging, monitoring, or security without directly impacting the core logic of the main application, decoupling infrastructure concerns from domain and application ones.

This also allows it to be written in a different language, with a completely different set of dependencies, which can be extremely powerful in companies with multi-disciplinary teams (think a Node.js app with a logger written in Rust or Zig).

Pros:

1. Separation of concerns: The sidecar pattern defines clear, segregated modules, allowing independent updates and changes.

2. Scalability: Sidecars enable scaling services without triggering a ripple effect across the entire application, providing a precise scalability solution.

3. Reusability: Components housed in sidecars can be (and usually are) reused.

4. Flexibility: As mentioned, the sidecar is independent from the main app, so it can be written in any language and have its own dependencies.

Cons:

1. Increased complexity: Implementing the sidecar pattern introduces complexities in managing communication between the main application and its sidecar, requiring careful attention during debugging. It also can create sidecars that are too generic, either forcing apps to conform to their narrow interfaces, or having excessively large interfaces. The alternative is maintaining multiple possible sidecars, which is hard in and of itself.

2. Resource overhead: Running multiple containers, especially for smaller services, can lead to increased resource consumption.

3. Harder deployment: Coordinating the deployment of both the main application and its sidecar demands meticulous orchestration, adding an additional layer of complexity to the deployment process.

4. Testing woes: Managing the sidecar can be tough for testing. It must be mocked or the app configured to run without it.

Sources:
Eraser.io
Microsoft's Architecture Centre

Feel free to leave a comment and/or reaction if this was useful or interesting to you!
Constructive criticism is very welcome too