Stackbook Logo
architecture-descriptionestablished · high operational burden

Service Mesh

Also known as: mesh, istio, linkerd, consul-connect

Intent

Dedicated infrastructure layer for service-to-service communication: mTLS, traffic management, observability, resilience — without application code changes.

Problem

Cross-cutting concerns (security, observability, resilience) implemented per-service creates inconsistency, duplication, and operational burden.

Forces

  • •Hundreds of services need consistent mTLS, retries, timeouts
  • •Application developers shouldn't implement infrastructure concerns
  • •Need uniform observability (metrics, traces, logs) across all services
  • •Traffic shifting for canary, blue-green, fault injection

Solution

✓ When to Use

  • •50+ services with complex service-to-service communication
  • •Need consistent mTLS without app changes
  • •Platform team owns infrastructure, app teams own business logic
  • •Progressive delivery (canary, A/B) required

✗ When Not to Use

  • •Small number of services (<20)
  • •Team lacks platform engineering capacity
  • •Simple architectures where sidecar overhead exceeds benefit
  • •Latency-critical paths where extra hop hurts

Pros

  • +Uniform security, observability, resilience across all services
  • +Application code stays focused on business logic
  • +Powerful traffic management for safe deployments
  • +Zero-trust network by default

Cons

  • −Significant operational complexity (control plane, CRDs, upgrades)
  • −Resource overhead: sidecar per pod (CPU, memory, latency)
  • −Debugging: extra hop, mTLS obscures payload
  • −Learning curve: new abstractions, failure modes

Cost Profile

Infrastructure

High — control plane + sidecars (2x pods)

Operational

High — upgrades, cert rotation, troubleshooting

Cognitive

High — new mental model, debugging complexity

Failure Modes

  • Control plane down → config frozen, new pods can't join mesh

  • Sidecar crash → pod loses connectivity (mitigate: health checks)

  • mTLS cert rotation failure → service-to-service TLS errors

  • Resource exhaustion: sidecar OOM under load

Real-World Examples

Alternatives

  • api-gateway
  • sidecar-proxy
  • library-based
  • direct-mtls

Related Patterns

  • api-gateway
  • circuit-breaker
  • rate-limiting
  • mtls
  • distributed-tracing

Competency Domains

distribution communicationsecurity compliancereliability opseconomics evolution