API Gateway

Chapter 07 · Microservices and Architecture

An API gateway is the single entry point for clients into a system of microservices. It handles auth, rate limiting, routing, and request shaping so individual services can stay focused on business logic.

The need for a gateway

You have 30 microservices. The mobile app needs data from 8 of them to render the home screen. Without a gateway, the app makes 8 calls, handles 8 different auth flows, deals with 8 retry strategies. Painful. Slow.

The API gateway sits between clients and microservices. It does the cross-cutting work and forwards trimmed requests to the right backends. The client sees one well-shaped API; behind it, the swarm of services is hidden.

What gateways typically do

Routing. /users/* goes to the user service, /orders/* to the order service.
Authentication and authorization. Validate tokens once at the edge. Backend services don't reinvent auth.
Rate limiting. Per user, per IP, per API key.
Request/response transformation. Mobile clients see a leaner JSON than the wire protocol.
SSL termination. Terminate HTTPS once.
Caching. Cache GET responses for popular reads.
Circuit breaking and retries. Protect downstream services from being hammered.
API composition. Sometimes the gateway calls multiple services and merges the responses.
Logging and tracing. One place to capture request metadata.

One gateway, many services. Cross-cutting concerns live at the edge.

Gateway vs reverse proxy vs load balancer

An API gateway is a specialized reverse proxy with API-aware features. NGINX in basic mode is a reverse proxy. NGINX with auth modules and rate limiting is closer to a gateway. Kong, Tyk, AWS API Gateway, and Envoy with custom filters are full-fledged gateways.

The Backend-for-Frontend (BFF) pattern

Some teams run multiple gateways: one for mobile, one for web, one for partners. Each shapes responses for its consumer. The mobile gateway returns thin payloads optimized for low bandwidth. The web gateway returns richer ones. Same backend services, different facade.

Don't put business logic in the gateway The gateway is for cross-cutting concerns. Business rules belong in services. Once you start gating logic in the gateway ("if user is premium, route here"), you've created a hidden service nobody owns. Keep the gateway thin.

Failure modes

The gateway is on the critical path of every request. If it dies, everything dies. Run multiple instances, with health checks, load balancers in front, fast failover. Test what happens when a downstream service is slow; the gateway must not stall on it.

← Previous

Monolith vs Microservices

Service Discovery