Microservices Patterns : Sidecar Pattern
Microservices Design Pattern Part 7 : Offloading Infrastructure So Your Services Stay Clean
The Problem No One Wants to Solve Twice
You have 12 microservices.
Your platform team wants mTLS enforced across all internal communication.
Your security team wants distributed tracing.
Your infra team wants centralized log shipping.
Your secrets team needs automatic credential rotation.
None of this is business logic.
But in a polyglot microservice fleet — Java here, Go there, Python somewhere else — there’s no shared codebase to put it in. You end up implementing the same concerns in every service, in every language, across every team.
That’s the problem the Sidecar pattern was designed to eliminate.
What Is the Sidecar Pattern?
The Sidecar pattern deploys a secondary process alongside your primary service — in a separate container, but within the same execution unit (typically a Kubernetes pod).
The responsibility split is simple:
- The primary service handles business logic
- The sidecar handles infrastructure concerns — observability, security, traffic management, and configuration
The name comes from a motorcycle sidecar: attached, sharing the journey, but not powering the engine. You can replace or upgrade it without touching the motorcycle.
The sidecar and the primary container share the network namespace, filesystem (via volumes), and optionally the process namespace. This co-location is what makes the pattern powerful.
Both containers communicate over localhost.
How Traffic Actually Flows
Most sidecar implementations use transparent traffic interception.
When proxies like Envoy Proxy run as sidecars — as in Istio, AWS App Mesh, or Consul — iptables rules redirect all inbound and outbound traffic through the sidecar.
The application still binds to its port. It has no idea the sidecar exists.
The application sends and receives plain HTTP or gRPC.
All infrastructure complexity is handled by the sidecar.
Use Case 1: Observability
Observability is one of the most common use cases for sidecars.
Different services use different languages, frameworks, and logging/tracing libraries. Standardizing observability using shared libraries means maintaining multiple implementations.
Sidecars solve this by centralizing the concern.
- Log shipping: The application writes logs to stdout or a shared volume. A Fluent Bit or Filebeat sidecar collects and ships them to a backend like Elasticsearch or Loki.
- Metrics: Prometheus expects a
/metricsendpoint. If the application doesn’t expose one, a sidecar can handle it. - Distributed tracing: An OpenTelemetry Collector sidecar receives spans, batches them, and exports to systems like Jaeger or Zipkin.
The application emits data.
The sidecar manages the pipeline.
Use Case 2: Security — mTLS and Zero Trust
Implementing mTLS inside every service means dealing with:
- Certificate loading
- Rotation
- TLS handshakes
- Validation logic
Across every language and team.
With a sidecar, all of this is handled externally.
The application communicates over plain HTTP. The sidecar:
- Terminates TLS on inbound requests
- Verifies client certificates
- Establishes TLS on outbound requests
- Injects the correct identity
Certificates are provisioned by a control plane and rotated automatically. The application does not need to restart.
Sidecars also enforce authorization policies:
“Only order-service can call payment-service”Without Sidecars:
Compromised Service → Any Service ✅
With Sidecars:
Compromised Service → Unauthorized Service ❌This is zero-trust networking — every request is verified at every hop.
Use Case 3: Traffic Management
When retry logic, timeouts, and circuit breakers are implemented inside services, they quickly diverge across teams.
Sidecars externalize this logic.
- Retries and timeouts: Configured once, applied consistently
- Circuit breaking: Prevents cascading failures by failing fast
- Traffic splitting: Enables canary deployments and A/B testing
For example, with Istio:
- 90% of traffic → v1
- 10% → v2
No application changes required.
Traffic behavior becomes configuration, not code.
Use Case 4: Secrets and Configuration Injection
The traditional approach to secrets — environment variables — creates static, long-lived credentials that are difficult to rotate and easy to leak.
Get Abhinav Thakur’s stories in your inbox
Join Medium for free to get updates from this writer.
A sidecar-based approach improves this significantly.
Using a Vault Agent sidecar:
- Secrets are fetched dynamically
- Stored in shared memory
- Automatically rotated
The application reads secrets as files. No SDK, no restart, no manual rotation.
The same pattern applies to configuration using tools like Consul Template, which updates configuration files dynamically.
Real-World Implementations
The sidecar pattern underpins many modern infrastructure tools:
- Envoy Proxy — data plane for service meshes
- Istio — service mesh platform
- Dapr — runtime for state, pub/sub, and service invocation
- Fluent Bit / Filebeat — logging
- OpenTelemetry Collector — observability
Dapr Example
Dapr exposes a local API:
localhost:3500/v1.0/state/statestoreThe application interacts with localhost. Dapr handles the backend (Redis, DynamoDB, etc.).
Trade-offs
The sidecar pattern introduces overhead and complexity.
Resource Overhead
Each pod runs an additional container. An Envoy sidecar typically consumes 50–100 MB of memory.
Latency
Every request passes through an extra proxy hop. Even if minimal, this adds up in high-frequency systems.
Operational Complexity
Sidecars must be configured, upgraded, and monitored independently. Misconfiguration can lead to difficult debugging scenarios.
Startup Ordering
If the sidecar isn’t ready when the application starts, initial requests may fail. Newer Kubernetes versions improve this with native sidecar lifecycle support.
When to Use It
Use the sidecar pattern when:
- You have a polyglot service architecture
- You need consistent infrastructure behavior across services
- You want to enforce zero-trust security
- You want centralized policy control without modifying application code
Avoid it when:
- Your system is homogeneous and a shared library is sufficient
- You run short-lived batch workloads
- You are not operating in a containerized environment
The Core Insight
Every microservice architecture eventually faces a tension:
You want team autonomy, but you also need operational consistency.
Shared libraries don’t solve this. They require multiple implementations, leak infrastructure concerns into application code, and make upgrades difficult.
The sidecar pattern resolves this by moving infrastructure out of the application entirely.
The service focuses on business logic.
The sidecar handles everything else.
Final Mental Model
If there’s one way to remember this:
The API Gateway is a bouncer at the front door. The sidecar is a lock on every room inside the building.
You need both. They solve different problems.
Final Takeaway
The sidecar pattern exists because:
- Distributed systems have cross-cutting concerns
- Infrastructure needs consistency
- Application code should remain focused
It’s not the simplest approach.
But it is one of the most effective ways to scale infrastructure concerns without coupling them to business logic.
Sidecars let you scale infrastructure concerns without touching application code.
Thank you for reading until the end. Before you go:
- Please consider clapping and following the writer! 👏
- Connect me on LinkedIn
