API Gateway Patterns: Architecture and Use Cases

What Is an API Gateway?

An API gateway is a managed entry point that sits between external clients and your backend services. Every inbound API request passes through the gateway, which applies cross-cutting concerns — authentication, rate limiting, logging, routing — before forwarding the request to the appropriate upstream service.

The term "gateway" is intentional: like a physical gateway, it controls who enters, what they can do, and where they go. No client talks directly to a backend service; all traffic flows through a single, programmable choke point.

Client → API Gateway → /users       → Users Service
                    → /orders      → Orders Service
                    → /payments    → Payments Service
                    → /inventory   → Inventory Service

This pattern emerged from microservices architectures, where an application is split into many small independent services. Without a gateway, every service must implement authentication, rate limiting, TLS termination, and logging independently — a significant and error-prone duplication of effort.

Gateway vs Reverse Proxy vs Load Balancer

These three tools share overlapping responsibilities, which causes confusion. Understanding the distinctions helps you choose the right tool for each layer.

Reverse Proxy

A reverse proxy (Nginx, HAProxy, Caddy) accepts connections on behalf of a server and forwards them upstream. Its primary concerns are TLS termination, connection pooling, and simple routing. Reverse proxies are typically configured with static rules:

# Nginx reverse proxy — static upstream
location /api/ {
    proxy_pass http://backend:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

A reverse proxy does not understand the content of requests, apply authentication policy, or count API calls per client. It routes — nothing more.

Load Balancer

A load balancer distributes traffic across multiple instances of the same service to ensure availability and spread load. It operates at the connection level (L4) or the HTTP level (L7). AWS ALB, GCP Cloud Load Balancing, and HAProxy can all do L7 load balancing. A load balancer knows about the *pool* of backends for a service, not about *which* service to route a particular request to.

API Gateway

An API gateway combines the routing capabilities of a reverse proxy with application-layer awareness. It understands API contracts, authenticates callers, enforces quotas, and can transform payloads. Most gateways can also do load balancing across service instances. The distinguishing feature is programmability: you configure per-route policies (authentication, rate limits, timeouts) rather than static forwarding rules.

Capability	Reverse Proxy	Load Balancer	API Gateway
TLS termination	Yes	Yes	Yes
Routing by path	Yes	Partial	Yes
Authentication	No	No	Yes
Rate limiting	No	No	Yes
Request transformation	No	No	Yes
Protocol translation	No	No	Yes
Analytics & metering	No	No	Yes

Core Gateway Capabilities

Request Routing

The gateway inspects the incoming request — URL path, HTTP method, headers, query parameters — and determines which upstream service should handle it. Advanced gateways support content-based routing (route GraphQL queries by operation type) and traffic splitting (send 5% of traffic to a canary deployment).

Authentication and Authorization

Rather than every service implementing JWT validation independently, the gateway validates tokens centrally. After verification, it injects identity information (e.g., X-User-ID: 12345) into the upstream request so services receive pre-authenticated context without re-validating credentials.

Rate Limiting and Quotas

The gateway tracks request counts per API key, IP, or user and rejects requests that exceed configured thresholds. This protects backends from abuse and enables tiered pricing (free tier: 1,000 req/day; paid tier: 100,000 req/day).

Request and Response Transformation

Gateways can add headers, rename JSON fields, strip sensitive data from responses, or convert between protocols (REST to gRPC, HTTP to WebSocket). This decouples the client-facing API contract from internal service implementation details.

Observability

Every request passes through the gateway, making it the ideal place to record structured access logs, emit metrics (latency histograms, error rates), and propagate distributed tracing headers (W3C Trace Context, Jaeger).

The Backend-for-Frontend (BFF) Pattern

A BFF is a specialized API gateway instance tailored to a specific client type. Instead of one generic gateway serving mobile, web, and partner APIs alike, you deploy separate gateways — one that aggregates and transforms data optimally for the mobile app, another for the web SPA, and a third for third-party integrations:

Mobile App  → BFF-Mobile  → aggregates 3 services into 1 response
Web SPA     → BFF-Web     → returns richer data, larger payloads
Partners    → BFF-Partner → enforces stricter auth, usage quotas

This avoids the problem of designing a single API that satisfies all clients poorly. The BFF pattern is commonly implemented using GraphQL (one schema, each client queries exactly what it needs) or using service-specific REST aggregation.

Gateway Products

Kong

Kong is the most popular open-source API gateway, built on Nginx/OpenResty. It uses a plugin architecture — authentication, rate limiting, logging, and transformations are all plugins configured via the Admin API or declarative YAML:

# Kong declarative config (deck)
services:
  - name: users-service
    url: http://users-service:8080
    routes:
      - name: users-route
        paths: ["/api/v1/users"]
    plugins:
      - name: jwt
      - name: rate-limiting
        config:
          minute: 100
          policy: redis

AWS API Gateway

AWS API Gateway (both REST and HTTP API variants) integrates natively with Lambda, ECS, and ALB backends. HTTP API is the newer, faster, cheaper variant — REST API supports more legacy features like request/response mapping templates:

{
  "openapi": "3.0.1",
  "paths": {
    "/users": {
      "get": {
        "x-amazon-apigateway-integration": {
          "type": "HTTP_PROXY",
          "uri": "http://users.internal/users",
          "httpMethod": "GET"
        }
      }
    }
  }
}

Envoy Proxy / Istio

Envoy is a high-performance L7 proxy used both as a standalone gateway (in Istio's ingress gateway) and as a sidecar proxy in service meshes. Envoy's xDS API allows dynamic configuration updates without restarts — making it the foundation for Istio, Contour, and Ambassador.

Other Options

Nginx Plus — commercial Nginx with API gateway features
Tyk — open-source Go-based gateway with a rich developer portal
Apigee — Google's enterprise API management platform
Traefik — cloud-native gateway with automatic service discovery

Anti-Patterns to Avoid

Gateway as Business Logic Layer

The gateway should handle cross-cutting infrastructure concerns, not business logic. If you find yourself writing Lua scripts that calculate pricing, apply discount rules, or make decisions about which data to return, that logic belongs in a service — not in the gateway. Gateways are hard to test, hard to version, and have limited language support compared to application code.

Single Point of Failure

A gateway that runs as a single instance becomes a critical single point of failure for your entire API surface. Run multiple gateway instances behind a load balancer, deploy across availability zones, and implement health checks and automatic failover. Most managed gateways (AWS API Gateway, Apigee) handle this for you; self-hosted gateways (Kong, Envoy) require explicit HA configuration.

Over-Centralization

Routing every byte of traffic through a single gateway creates a latency tax and a deployment bottleneck. Service-to-service traffic inside your cluster does not need to traverse the gateway — use a service mesh or direct service discovery for internal calls. The gateway is for north-south traffic (external clients to internal services), not east-west (service to service).

Summary

An API gateway is the programmable entry point for your API — handling routing, authentication, rate limiting, and observability in one place so each microservice does not have to. Choose a gateway that fits your operational model: AWS API Gateway for serverless-heavy AWS shops, Kong or Tyk for self-hosted control, Envoy/Istio when you need a full service mesh. Keep business logic in services, run multiple gateway instances for HA, and limit the gateway's responsibility to infrastructure cross-cutting concerns.