Service-Mesh

Overview The Sidecar Pattern is the general technique of running a helper container alongside your app in the same pod to add any cross-cutting capability — logging, metrics, config sync, or a mesh proxy. The Ambassador Pattern is a specific flavor of that sidecar dedicated to one job: sitting between the app and the network, so the app talks to localhost while the ambassador handles the real, often messy, connection to an external service. ...

Overview An API gateway sits at the edge of your system, managing traffic between external clients and your services. A service mesh operates inside the cluster, managing traffic between services themselves. Confusing the two leads teams to either duplicate cross-cutting concerns or push edge-only features into infrastructure that was never designed for public-facing traffic. Comparison Diagram API GatewayService MeshClientAPI GatewayauthN · rate limitrouting · transformclusterService AService BService Csidecar proxymTLS · retriesnorth–south: client-to-serviceeast–west: service-to-service Comparison Table Aspect API Gateway Service Mesh Traffic direction North-south: external clients entering the system East-west: internal service-to-service calls Deployment topology Centralized cluster of edge instances fronting all traffic Sidecar proxy injected alongside every service instance Primary concerns AuthN/authZ, rate limiting, request/response transformation, API versioning mTLS, load balancing, retries, circuit breaking between services Routing basis Public API path, host, or version mapped to a backend service Service identity and destination within the internal network Observability scope Per-endpoint metrics: request volume, latency, errors by client Full service dependency graph: per-hop latency and error rates Failure containment Blocks or throttles bad traffic before it reaches any backend Isolates failures at individual hops so one bad service doesn’t cascade Operational overhead Few instances to scale and configure centrally One proxy per workload, plus a control plane to manage them all Key Differences An API gateway is the single entry point clients hit; a service mesh has no single entry point, it’s woven through every service. Gateways enforce policy once at the edge; meshes enforce policy per sidecar on every call. Gateways typically run as a small number of centralized instances; meshes scale linearly with your service count. Meshes give you mTLS and retries between internal services, something a gateway never sees because that traffic never reaches it. Many production systems run both together, not as alternatives, since they solve problems at different layers. When to Use Each API Gateway ...