Design an API Gateway — what responsibilities does it have and how does it route requests?

API Gateway Responsibilities

Client → API Gateway → Service A (users)
                   → Service B (orders)
                   → Service C (payments)

Cross-cutting Concerns (handled once at gateway)

Concern	Before Gateway	After Gateway
Authentication	Each service validates JWT	Gateway validates, passes user context
Rate limiting	Each service implements	Gateway enforces per-user limits
Logging	Each service logs differently	Gateway logs all requests uniformly
CORS	Each service handles	Gateway handles centrally
Request routing	Client knows all URLs	Client calls one domain
Circuit breaking	None	Gateway detects failures, short-circuits
Response caching	None	Gateway caches GET responses

Implementation (Kong / Nginx / Custom)

# nginx.conf
upstream user_service { server users:3001; }
upstream order_service { server orders:3002; }
upstream payment_service { server payments:3003; }

server {
    listen 443 ssl;

    # Auth check (all routes)
    auth_request /auth;
    auth_request_set $user_id $upstream_http_x_user_id;

    # Rate limiting
    limit_req_zone $user_id zone=api:10m rate=100r/s;

    # Routing
    location /api/users/ {
        proxy_pass http://user_service;
        proxy_set_header X-User-Id $user_id;
    }

    location /api/orders/ {
        limit_req zone=api burst=20;
        proxy_pass http://order_service;
    }

    location /api/payments/ {
        limit_req zone=api burst=5;
        proxy_pass http://payment_service;
    }

    location = /auth {
        internal;
        proxy_pass http://auth_service/verify;
    }
}

GraphQL Federation (Alternative)

// Single GraphQL endpoint → routes to multiple services
const gateway = new ApolloGateway({
  serviceList: [
    { name: "users", url: "http://users:3001/graphql" },
    { name: "orders", url: "http://orders:3002/graphql" },
    { name: "payments", url: "http://payments:3003/graphql" },
  ],
});
// Client sends one query, gateway fans out to relevant services

When You Need an API Gateway

• 3+ microservices with shared concerns
• Multiple client types (web, mobile, partner APIs)
• Need centralized auth, rate limiting, monitoring
• Migrating monolith → route old URLs to new services