API Gateway Fundamentals

An API gateway sits at the edge of a system and handles concerns that are shared across many APIs: routing, authentication, rate limiting, request transformation, observability, and sometimes caching. It is useful because it centralises policy, but it is not free. Every request now depends on one more component in the critical path.

What a gateway actually does

At minimum, a gateway receives external requests and forwards them to the right upstream service. In practice it often also terminates TLS, validates tokens, applies quotas, rewrites headers, normalises paths, and records traffic metrics. Some gateways aggregate responses from several services or expose a stable public surface while internal services evolve behind it.

This can simplify clients significantly. Mobile or browser applications talk to one consistent entry point instead of learning the topology of the whole back end.

Where a gateway helps most

Gateways are especially useful when many services need the same edge controls. Authentication logic, bot protection, request logging, and tenant-aware routing are easier to manage consistently in one place than in twenty separately deployed applications.

A gateway can also shield internal systems from external churn. Public APIs often need stronger backwards compatibility than internal service contracts. The gateway becomes the layer where protocol translation, deprecation, or path reshaping can happen with less disruption upstream.

The tradeoffs people underestimate

Because a gateway sees all traffic, it can become a bottleneck or single point of failure if it is not scaled and operated carefully. It can also turn into a dumping ground for business logic. Once teams start placing complex orchestration, field-level authorisation, or domain-specific transforms in the gateway, the edge layer becomes harder to test and harder to change safely.

Latency is another tradeoff. A gateway may add only a few milliseconds per request, but at high volume or in multi-hop architectures that overhead is still part of the budget.

Keep the boundary clean

The best gateways handle cross-cutting concerns, not core domain logic. Use them to authenticate requests, route traffic, apply quotas, and emit observability data. Keep business decisions in the services that own the domain model. That separation lets the edge remain stable even as application behaviour changes.

A good rule of thumb

Introduce a gateway when clients need one front door and the platform needs shared edge controls. Avoid turning it into a miniature application platform. When used with discipline, an API gateway simplifies exposure and governance. When overloaded, it becomes one more monolith in front of many smaller ones.