An API gateway handles traffic arriving from outside — authentication, rate limiting, routing, request shaping. A service mesh handles traffic between your own services — encryption, retries, observability, traffic shifting. North-south and east-west, in the usual shorthand.
Most organisations need the gateway long before they need the mesh. A gateway earns its place the moment you have more than one service exposed publicly and want authentication and rate limiting in one place rather than reimplemented in each. That threshold arrives early.
A service mesh earns its place much later. It solves problems that appear when you have many services, communicating heavily, across teams, and you need consistent encryption, retry behaviour and telemetry without modifying every service. With five services and one team, the mesh is more operational complexity than the problem it addresses.
The complexity is real and often understated. A mesh adds a proxy alongside every service, a control plane to run, and a new layer to debug when a request fails. Teams have adopted a mesh, hit a subtle routing problem, and spent longer diagnosing it than the mesh had saved.
Consider what your platform already provides. Cloud load balancers handle a meaningful subset of gateway functionality; Kubernetes ingress controllers handle routing; library-level retries and tracing cover part of what a mesh offers. Adding a component that duplicates something you already run is a common and avoidable cost.
If you do adopt either, own the failure modes before production. Know what happens when the gateway is unreachable, when a certificate in the mesh expires, when the control plane is down. These components sit in the path of every request, which is exactly why they are useful and exactly why their failure is total.
