API Gateway Patterns for Microservices

An API gateway sits between clients and your microservices, handling cross-cutting concerns — routing, authentication, rate limiting, request transformation, and aggregation. Without a gateway, every microservice implements these concerns independently (or doesn't).

Core Gateway Patterns

1. Reverse Proxy / Router

The simplest pattern. The gateway routes requests to the correct service based on URL path, headers, or other criteria.

Client → Gateway → /users/* → User Service
                  → /orders/* → Order Service
                  → /products/* → Product Service

Use when: You want a single entry point without duplicating routing logic across services.

2. API Aggregation (Backend for Frontend)

The gateway combines data from multiple services into a single response. The client makes one request instead of three.

Client: GET /api/dashboard
Gateway:
  → GET user-service/profile
  → GET order-service/recent
  → GET analytics-service/metrics
  → Combine → Single response

Use when: Frontend pages need data from multiple services. Reduces client-side complexity and round trips.

3. Authentication Gateway

The gateway handles authentication (JWT validation, API key verification) so individual services don't need to. The gateway passes the validated identity downstream via headers.

Client → Gateway (validate JWT) → X-User-Id: 123 → Service

Use when: You want centralized authentication instead of each service validating tokens independently.

4. Rate Limiting Gateway

The gateway enforces rate limits before requests reach your services. Protects backend services from abuse and ensures fair usage.

Use when: Multiple services need consistent rate limiting policies.

5. Request/Response Transformation

The gateway transforms requests and responses — header manipulation, body modification, protocol translation (REST → gRPC), and response filtering.

Client (REST/JSON) → Gateway (transform) → Service (gRPC/Protobuf)

Use when: Internal services use different protocols than external clients expect.

6. Circuit Breaker

The gateway monitors service health. When a service fails repeatedly, the gateway "opens the circuit" — returning cached responses or errors without forwarding requests to the failing service.

Use when: Cascading failures are a risk (one slow service brings down everything).

Gateway vs Service Mesh

Concern	API Gateway	Service Mesh (Istio/Linkerd)
Position	Edge (external traffic)	Internal (service-to-service)
Auth	External client auth	mTLS between services
Rate limiting	Per-client limits	Per-service limits
Routing	URL path, host, headers	Service name, labels
Observability	External request metrics	Internal traffic metrics
Aggregation	✅ Yes	❌ No
Complexity	Medium	High

Most architectures use both: Gateway at the edge for external traffic + service mesh for internal communication.

Choosing a Gateway

Gateway	Best For	Type
Kong	Self-hosted, plugin ecosystem	Open source
Zuplo	Edge-deployed, developer-first	Cloud
AWS API Gateway	Serverless + Lambda	Cloud
Envoy	Service mesh, high performance	Open source
Traefik	Kubernetes-native	Open source
NGINX	Simple reverse proxy	Open source
Cloudflare	Edge + security	Cloud

Anti-Patterns

Anti-Pattern	Problem	Solution
Business logic in gateway	Gateway becomes a monolith	Keep gateway thin — routing, auth, rate limiting only
Gateway as single point of failure	One gateway failure = total outage	Multiple gateway instances, health checks
Over-aggregation	Gateway becomes tightly coupled to all services	Limit aggregation to BFF patterns
No circuit breaker	Slow service blocks gateway threads	Implement timeouts and circuit breakers
Gateway per team	Inconsistent policies, management overhead	Shared gateway with per-team configuration

Building microservices architecture? Explore Kong, API gateways, and more on APIScout — comparisons, guides, and developer resources.

Comments