SA-301b · Module 3

Service Mesh Architecture

4 min read

A service mesh moves inter-service communication concerns — retries, circuit breaking, load balancing, mutual TLS, observability — out of the application code and into infrastructure. Instead of every service implementing its own retry logic and circuit breakers, a sidecar proxy handles it transparently. The application code makes a plain HTTP call; the sidecar handles the rest. This is the right architecture when the number of services and communication patterns exceeds what teams can manage manually.

Do This

  • Adopt a service mesh when the service count exceeds what teams can manage with in-app communication libraries — typically 15-20 services
  • Start with observability and mTLS — the highest-value features with the lowest configuration complexity
  • Roll out incrementally — add sidecars to services one at a time, starting with non-critical services

Avoid This

  • Deploy a service mesh for five services — the operational overhead exceeds the benefit at that scale
  • Enable every mesh feature simultaneously — start with the features that solve your current pain points
  • Skip the team training — a service mesh adds a new infrastructure layer that the operations team must understand and debug