In short
An API gateway is an upstream component that serves as the central entry point for all requests to a system. Instead of a client talking directly to dozens of individual services, it sends its requests to the gateway, which forwards them to the right back-end service in each case and takes care of authentication, rate limiting, logging and much more along the way.
You can think of an API gateway as the reception of a large office complex: visitors register at a single point, are checked, logged and then directed to the right contact person, instead of wandering uncontrolled through all the floors. For you as a decision-maker, the gateway is often the place where central requirements such as security, traceability and load protection are bundled and enforced uniformly.
Why an API gateway?
The importance of API gateways has grown strongly with the rise of microservices. In a monolithic application there is a single entry point, and things are simple. But as soon as a system consists of ten, twenty or a hundred small services, a problem arises: should every client know which service can be reached at which address? Should every service implement its own authentication, its own rate limiting, its own TLS termination? That would be error-prone, redundant and hard to maintain. The API gateway solves this problem by bundling these cross-cutting tasks in a single place.
For the client this means a drastic simplification: it only knows one address and one uniform interface. The internal structure of the back end (how many services there are, where they run, which language they are written in) remains hidden. The back end can evolve freely behind it; services can be split, merged or replaced without the client noticing anything. This decoupling is one of the greatest strategic advantages of a gateway.
Then there is the governance aspect, which matters especially in a B2B environment: when you give external partners access to your APIs, you want to be able to control exactly who may do what and how often. A gateway is the natural place to issue API keys, allocate usage quotas per partner, offer individual versions of an API in parallel and block access immediately if necessary. Without a gateway, this central control over access to your interfaces can only be achieved with considerable extra effort and many scattered special solutions.
Typical tasks of an API gateway
- Routing: forwarding requests to the right back-end service on the basis of path, host or header.
- Authentication and authorisation: central checking of API keys, JWTs or OAuth tokens before a request even reaches the back end.
- Rate limiting and throttling: protection against overload and misuse by limiting the number of requests per client.
- TLS termination: decrypting HTTPS in one place so that the internal services do not have to deal with it.
- Caching: storing frequent responses temporarily and relieving the back end.
- Request/response transformation: adapting formats, adding headers, combining several back-end responses into one (aggregation).
- Observability: central logging, metrics and tracing of all requests.
Because all these tasks converge in the gateway, the individual back-end services stay lean and concentrate on their actual business logic. That is separation of concerns in practice.
The observability aspect is particularly underestimated in practice. Because every request passes through the gateway, it is the ideal place to gain a complete picture of the traffic: how many requests come in, which endpoints are used most, where do errors pile up, how are response times distributed? With distributed tracing, the gateway can give every request a unique correlation ID that runs through all downstream services, so that a problem can later be traced back step by step through the entire call chain. Especially when a system consists of many services, this central view is often the difference between a cause found in minutes and a search in the dark that lasts for hours.
Well-known API gateway solutions
The market offers a range of established products. Kong is a popular open-source gateway based on NGINX with an extensive plugin system. AWS API Gateway is Amazon's fully managed service, closely integrated with Lambda and the rest of the AWS ecosystem. Azure API Management and Google Cloud Apigee are the counterparts of the other major cloud providers. In the Kubernetes environment, an ingress controller or a service mesh such as Istio often takes on similar tasks. For simpler set-ups, NGINX or Traefik are also widespread as lightweight reverse proxies that cover many gateway functions.
Which solution fits depends heavily on your infrastructure: anyone who relies on AWS anyway often opts for AWS API Gateway; anyone who wants to remain platform-independent often chooses Kong or Traefik. A detailed conceptual classification is provided by Chris Richardson's directory of microservices patterns.
API gateway, reverse proxy and load balancer: what is the difference?
These three terms are often confused because they overlap. The following table puts them into context:
| Component | Main task | Focus |
|---|---|---|
| Load balancer | Distributing requests across several identical instances | Load distribution, availability |
| Reverse proxy | Accepting requests and passing them on to back ends | Mediation, TLS, caching |
| API gateway | Reverse proxy plus API-specific logic (auth, rate limiting, aggregation) | API management, security |
Put simply: an API gateway is a specialised reverse proxy with an understanding of APIs. It not only knows where a request should go but also understands what it means in terms of content, and can handle it accordingly. In practice, a gateway often also takes on load-balancing tasks, so the boundaries are fluid.
A concrete example from e-commerce
Take a modern online shop that is made up of several specialised services according to the composable commerce principle: one service for the product catalogue (often fed from a PIM), one for the basket, one for orders, one for search, one for payments. Without a gateway, the front end would have to know at which address each of these services is located and perhaps make four or five separate calls for a single product page. With an API gateway, the front end instead calls a single endpoint, such as /api/product/4711. The gateway fetches the master data, price, stock level and reviews from the respective services in parallel, combines them into one response and returns it as a bundle. From the front end's point of view, it looks as if there were only one service; the complexity stays neatly hidden behind the gateway. This aggregation is one of the most common reasons for introducing a gateway in headless and composable environments.
The BFF pattern: one gateway per client
A common refinement is the backend-for-frontend pattern (BFF). Instead of a single, universal gateway, you build a tailor-made gateway for each type of client: one for the web application, one for the mobile app, one for partner integrations. The reason: a mobile app has completely different requirements for data volume and response format than a desktop front end. A BFF can tailor the responses precisely to the respective client, bundle several back-end calls and thus minimise the number of round trips, which is particularly valuable on mobile networks. This pattern combines well with GraphQL, which can serve as a flexible aggregation layer in the BFF.
The price of this pattern is more code that has to be maintained: each BFF is a component of its own with its own life cycle. The rule of thumb is therefore to introduce a BFF only when the requirements of the clients actually diverge, and not as a precaution. With two similar web front ends, a shared gateway is often enough; with an app, a complex web dashboard and a partner API, the different needs usually justify the extra effort quickly.
What to look out for when using one
As useful as an API gateway is, it also brings risks. The biggest: it easily becomes a single point of failure. If the gateway fails, the entire back end can no longer be reached, however healthy the individual services are. That is why a gateway must always be designed redundantly and monitored carefully. The second risk is complexity: an overloaded gateway into which more and more business logic migrates itself becomes a monolith that is hard to maintain, the so-called "gateway monolith". The rule of thumb is therefore: cross-cutting concerns yes, business logic no. Third, the additional latency should be kept in view, even though it is usually low with well-configured gateways. Anyone who observes these points gets a powerful tool with an API gateway for keeping a growing service landscape manageable, secure and uniform towards the outside.
In our enterprise projects we therefore deliberately introduce a gateway step by step: first as a lean entry point for routing and TLS, then supplemented with authentication and rate limiting, and only later with aggregation where it adds real value. This order prevents the gateway from being overloaded from the start and keeps it as maintainable as it is meant to be. In the end, an API gateway is not an end in itself but an investment in operability: it makes a growing system simple towards the outside and manageable on the inside, provided you resist the temptation to pack too much into it.
Frequently asked questions about API gateways
Do I need an API gateway even without microservices?
Not necessarily. With a single back end, a simple reverse proxy is often enough. The full benefit of a gateway unfolds as soon as several services are to be bundled behind a uniform interface.
What is the difference between an API gateway and a load balancer?
A load balancer distributes requests across identical instances. An API gateway also understands the API level and takes on auth, rate limiting, routing by path and aggregation. A gateway can include load balancing but is considerably more.
Does an API gateway make my API slower?
It adds an extra hop, which costs minimal latency. With a good configuration this is negligible and is often more than offset by caching and bundled calls.
Is an API gateway a security risk?
On the contrary: used correctly, it increases security, because authentication, TLS and rate limiting are enforced centrally and consistently. However, it must itself be hardened and operated redundantly.
Which API gateway should I choose?
That depends on your infrastructure. In the AWS world, AWS API Gateway is the obvious choice; Kong or Traefik are widespread platform-independent options; in a Kubernetes context it is often an ingress controller or Istio.