API gateway: One entry point for many services

In short: An intermediary that accepts all requests from outside and forwards them to the appropriate internal services.

In more detail: With many small services (microservices) it would be cumbersome if every app had to know and secure each service individually. An API gateway bundles access: it has one address, checks the requests and distributes them. Cross-cutting tasks are thus solved once centrally instead of in every service.

In Depth

Tasks

• Routing: /orders goes to the order service, /users to the user service.
• Authentication and authorization: checking tokens before anything reaches the services.
• Rate limiting and protection against abuse.
• TLS termination: encryption at the entrance, simpler internally.
• Combining several responses into one (aggregation) and reshaping formats.
• Logging, metrics, caching.

Example of a routing rule

In nginx-like notation:

location /api/orders/ { proxy_pass http://orderservice:8080/; }
location /api/users/  { proxy_pass http://userservice:8080/; }

In practice one uses products such as Kong, Traefik, AWS API Gateway or Azure API Management.

Backend for frontend (BFF)

A variant is a separate gateway per type of application, for example one for the mobile app and one for the web interface. Each delivers exactly the data its client needs and avoids many individual calls.

Disadvantages

The gateway is a central point: if it fails, everything is gone, and it can become a bottleneck. It should therefore be run redundantly and highly available. It also must not accumulate too much business logic, otherwise a new monolith emerges. Pure service-to-service traffic usually does not run through it but through a service mesh.

See also: Microservices, nginx and reverse proxy, Rate limiting, Load balancer