Overview

The API Gateway pattern is motivated by the problems that arise when client applications make requests directly to the APIs of individual microservices. The API Gateway is a service that implements the single entry point from outside the firewall to the backend microservices.

Problem

In a microservices architecture, client applications making direct requests to individual microservice APIs face several problems:

  • Different clients (mobile, desktop, third-party) have different needs and resources
  • Direct client access exposes the internal architecture, making it harder to evolve without breaking clients
  • Clients typically communicate via HTTP or WebSockets, while internal microservices may use protocols such as RPC or AMQP
  • Clients must make multiple requests and compose data themselves when operations span several microservices

Solution

The API Gateway service is responsible for encapsulating the architecture, routing and load balancing requests from outside the firewall, API composition, and other functions typically placed at the backend edge — known as edge functions — such as: authentication, authorisation, rate limiting, caching, metrics collection, logging, service discovery, and circuit breakers.

Problems Solved

Diverse clients: the API Gateway allows the implementation of different APIs for different types of client, tailored to their needs and resources. For example, a mobile application typically has a smaller user interface and fewer network resources than a desktop application, so the quantity and quality of data it receives should be reduced accordingly.

Lack of encapsulation: the API Gateway encapsulates and abstracts clients from the internal architecture. As long as the Gateway API is maintained, backend developers can make internal changes without requiring modifications on the client side. It also allows old API versions to be maintained for clients that have not yet been updated.

Protocol mismatch: the API Gateway acts as a protocol adapter — communicating with clients via HTTP or WebSocket, while internally microservices can use the most appropriate mechanism (HTTP, WebSocket, RPC, AMQP, etc.).

Technologies

Technologies for implementing the API Gateway and edge functions include: NGINX, Kong, Traefik, Netflix Zuul, Spring Cloud Gateway, AWS API Gateway, and AWS Load Balancer.

Trade-offs

Benefits

  • Encapsulates the internal architecture — clients are decoupled from microservice boundaries
  • Tailored APIs for different client types and their specific needs and resources
  • Reduces the need for client-side changes when the internal architecture evolves
  • Simplifies client code — no need for multiple requests or client-side API composition

Drawbacks

  • Increased complexity — an additional component to develop, deploy, and maintain
  • Risk of becoming a bottleneck (single point of entry for all requests)
  • Developers need to update Gateway APIs at runtime, requiring processes that are lightweight and do not negatively impact system usage

When to Use

Apply API Gateway when:

  • Multiple types of clients with different needs access the system
  • You want to hide the internal microservices architecture from external clients
  • Cross-cutting concerns (authentication, rate limiting, logging) should be centralised

Consider alternatives when:

  • Only one type of client exists — a simpler reverse proxy may suffice
  • Consider Backends for Frontends when different client types require very different API contracts that are better managed by separate teams

References