The Sidecar Pattern for Application Developers

The sidecar pattern
  • Many sidecar based solutions do not interact with user code at all, and thus do not replace libraries. Common examples include service meshes that rely on network level interception of the application traffic to perform mutual authentication, retries, and telemetry monitoring.
  • Sidecar based solutions that interact with user code like Hazelcast and Dapr provide libraries for developers to consume from popular package managers like npm, pip, NuGet and others. These libraries are then used to interact with the sidecar.



  • Dependencies are isolated per business unit. A breach in a dependency that an API server uses cannot compromise code and dependencies of an authentication business unit.
  • Developers now have a much broader set of defense mechanisms in the form of HTTP1.1/gRPC servers with a wide array of communication protocols to choose from (Unix Domain Sockets, Named Pipes, TCP etc.)

Code Reusability

Resource Allocation

  1. Consume events (I/O bound)
  2. Process (CPU bound)
  3. Write to database (I/O bound)

Final Thoughts



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Yaron Schneider

Yaron Schneider

Co-Founder / CTO at Diagrid. Co-Creator of CNCF projects Dapr and KEDA. Author of Learning Dapr. Distributed Systems geek.