API Gateway Patterns for Microservices

API Gateway Patterns for Microservices

An API Gateway is the single entry point for all client requests in a microservices architecture. It handles routing, authentication, rate limiting, and response aggregation — simplifying client interactions with your backend services.

Why Use an API Gateway?

• Single entry point — Clients interact with one URL, not dozens of service endpoints
• Cross-cutting concerns — Authentication, rate limiting, logging applied once
• Protocol translation — REST to gRPC, WebSocket to HTTP
• Response aggregation — Combine data from multiple services in one response
• Client isolation — Internal service architecture changes don't affect clients

Gateway Patterns

1. Simple Routing Gateway

# Route based on path prefix
/api/users/*    → User Service
/api/orders/*   → Order Service
/api/payments/* → Payment Service
/api/search/*   → Search Service

2. Backend for Frontend (BFF)

Create separate gateways optimized for different client types:

Mobile BFF Gateway (/mobile/*)
  → Aggregates data for mobile screens
  → Optimized payloads (smaller, fewer fields)
  → Mobile-specific authentication

Web BFF Gateway (/web/*)
  → Richer responses for web UI
  → WebSocket support
  → Session management

Partner API Gateway (/partner/*)
  → API key authentication
  → Rate limiting per partner
  → Versioned endpoints

3. Response Aggregation

# Single client request:
GET /api/dashboard

# Gateway makes parallel calls:
→ User Service: GET /users/me
→ Order Service: GET /orders?user=me&status=active
→ Analytics Service: GET /metrics?user=me

# Gateway combines responses:
{
  "user": { ... },
  "activeOrders": [ ... ],
  "metrics": { ... }
}

AWS API Gateway

# REST API with Lambda integration
aws apigateway create-rest-api --name "Microservices API"

# HTTP API (cheaper, simpler)
aws apigatewayv2 create-api \
  --name "Microservices HTTP API" \
  --protocol-type HTTP

# Integration with ALB/NLB backends
aws apigatewayv2 create-integration \
  --api-id xxx \
  --integration-type HTTP_PROXY \
  --integration-uri arn:aws:elasticloadbalancing:...:listener/xxx

Kong Gateway (Self-Hosted)

# Deploy Kong on Kubernetes
helm install kong kong/kong \
  --namespace kong \
  --set proxy.type=LoadBalancer \
  --set ingressController.enabled=true

# Configure route
apiVersion: configuration.konghq.com/v1
kind: KongIngress
metadata:
  name: api-route
route:
  strip_path: true
  paths:
  - /api/users
upstream:
  host_header: user-service.production.svc

Cross-Cutting Concerns

Gateway Anti-Patterns

• Business logic in the gateway — Keep it thin; routing and security only
• Single point of failure — Deploy gateway in HA with auto-scaling
• Over-aggregation — Complex aggregation belongs in a dedicated BFF service
• Tight coupling — Gateway should not know about service internals

Eazy SaaS Tip: We start with AWS API Gateway (HTTP API) for its simplicity and cost-effectiveness, then migrate to Kong or custom gateways as requirements grow. For most SMBs, the managed service handles 90% of use cases at a fraction of the operational cost.