Why You Need an API Gateway (and When You Don't)

When clients talk directly to a dozen backends, the frontend ends up knowing every hostname, every auth scheme, and every error shape. An API gateway is one entry point that receives every request and forwards it to whichever service should handle it, so clients stop knowing your internal topology.

Its value is centralizing cross-cutting concerns: routing, rate limiting, TLS termination, request and response transformation, caching, observability, and above all authentication. Validating tokens in twelve services is twelve chances to get it wrong. One caveat teams miss constantly is that gateway token validation covers authentication only, and each service still has to enforce whether this user may touch this resource. Aggregating several backend calls into one client response is the Backend for Frontend idea, and a gateway handles north-south ingress while a service mesh handles east-west traffic between services.

The failure mode is business logic creeping into gateway config, which quietly builds a distributed monolith. With one or two services, skip it.