Reverse Proxy and API Gateway

A forward proxy acts on behalf of clients: clients send requests to it, and it fetches resources from the internet. A reverse proxy acts on behalf of servers: clients connect to the proxy, believing it is the server, and the proxy forwards requests to backend servers and returns their responses. Clients never contact backends directly. An API gateway is a reverse proxy specialized for APIs, which adds API-level concerns such as authentication, rate limiting, and request routing across many services.

Reverse proxy responsibilities

flowchart LR
    C["Clients"] --> RP["Reverse proxy"]
    RP --> A["Backend A"]
    RP --> B["Backend B"]
    RP --> D["Backend C"]

• TLS termination: the proxy holds certificates, performs the TLS handshake with clients, and forwards plain HTTP (or re-encrypts) to backends. This centralizes certificate management and moves encryption CPU work off application servers. Traffic on the internal network is then unencrypted unless re-encrypted, so environments with strict requirements use TLS or mutual TLS to backends as well.
• Routing: choose the backend by host name, path prefix, header, or method. For example /api/* to an API pool and /static/* to a static file server.
• Load distribution: spread requests across several instances of a backend (see load balancing).
• Caching: store cacheable responses and serve repeats without hitting the backend.
• Compression: gzip or Brotli responses.
• Connection handling: the proxy buffers slow clients, and keeps a small pool of persistent connections to backends. It absorbs many slow client connections so that backends spend less time on them.
• Protocol translation: accept HTTP/2 or HTTP/3 from clients and speak HTTP/1.1 to backends.
• Security: hide backend topology and addresses, filter malicious requests (as a web application firewall), and limit request size and rates.
• Header management: add X-Forwarded-For and X-Forwarded-Proto (or the standard Forwarded header) so backends can see the original client address and scheme.

Common software: NGINX, HAProxy, Envoy, Traefik, and Apache HTTP Server.

A minimal NGINX configuration that terminates TLS and routes by path:

upstream api_pool {
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
}

server {
    listen 443 ssl;
    server_name api.example.com;
    ssl_certificate     /etc/ssl/api.example.com.crt;
    ssl_certificate_key /etc/ssl/api.example.com.key;

    location /api/ {
        proxy_pass http://api_pool;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

X-Forwarded-For accumulates a list of addresses, and a client can send its own value. Backends should trust only the entries appended by proxies they control, and the outermost proxy should overwrite or validate incoming values.

API gateway responsibilities

An API gateway is the single entry point for client requests into a system of services, typically microservices. It provides a public API and hides the internal service layout.

• Request routing to the appropriate service, mapping public paths to internal services.
• Authentication and authorization: validate credentials at the edge, such as API keys, JWTs (verified locally with the issuer's public key, or checked with the identity provider for opaque tokens), or OAuth2 tokens (see authentication, OAuth2, JWT, and sessions), and pass the verified identity to services in headers. Services still enforce fine-grained authorization.
• Rate limiting and quotas per client, key, or plan (see rate limiting algorithms).
• Request aggregation (composition): one client request triggers several backend calls whose results are merged, reducing round trips for clients. If the calls are independent, the gateway issues them in parallel, so added latency is the slowest call rather than the sum, and it must define behavior when one call fails (return partial data or fail the request). See BFF and API composition.
• Protocol translation: expose REST or GraphQL to clients and call gRPC or messaging systems internally.
• Request and response transformation: rename fields, add headers, and version mapping between public and internal APIs.
• Resilience policies: timeouts, retries, and circuit breakers toward backends.
• Observability: central logging, metrics, and generation of a trace or correlation ID at the edge.
• Versioning and canary routing: route a fraction of traffic to a new version.
• Developer-facing features: API key management, usage analytics, and documentation portals in managed products.

Examples: Kong, AWS API Gateway, Apigee, Azure API Management, and Envoy-based gateways.

Request flow through a gateway

sequenceDiagram
    participant C as Client
    participant G as API gateway
    participant Auth as Identity provider
    participant O as Order service
    participant U as User service
    C->>G: GET /orders/1001 with bearer token
    G->>G: TLS termination, rate limit check
    G->>Auth: validate token (or verify JWT locally)
    Auth-->>G: identity and scopes
    G->>O: GET /orders/1001 with user ID header
    G->>U: GET /users/7
    O-->>G: order
    U-->>G: user
    G-->>C: merged JSON response

Reverse proxy versus load balancer versus API gateway

The categories overlap, since one product often fills several roles.

A load balancer treats backends as interchangeable instances of one service. A gateway routes among different services and applies policy per API. In a typical deployment: DNS leads to a cloud load balancer, which forwards to a gateway cluster, which routes to services, each of which sits behind its own internal load balancing (see service discovery).

Gateway versus service mesh

A gateway handles north-south traffic (clients into the system). A service mesh handles east-west traffic (service to service) through sidecar proxies. They are complementary.

Trade-offs and failure modes

• Single point of failure and bottleneck: all traffic passes through it. Run several stateless instances behind a load balancer, and scale horizontally. Keep gateway state (such as rate limit counters) in an external store, or accept approximate local limits.
• Added latency: an extra network hop and processing per request. Keep gateway logic thin.
• Business logic creep: putting domain logic or heavy orchestration in the gateway turns it into a shared component every team must change, which couples releases. Keep it to cross-cutting concerns, and use a BFF or a dedicated composition service for client-specific aggregation.
• Configuration risk: a faulty routing or auth rule affects every service, so changes need review, staged rollout, and fast rollback.
• Cache correctness: caching at the proxy needs correct cache keys (including Vary headers), or it can serve one user's response to another.
• Timeout mismatch: the gateway's timeout should be at least the sum of what is needed downstream, but shorter than the client's timeout, or work continues after clients give up.

When to use

• One entry point to several services with shared authentication and rate limits: an API gateway.
• A single application needing TLS termination, static caching, and compression: a reverse proxy alone is sufficient.
• Public API with external developers, quotas, and keys: a gateway with a management layer.
• Small system with one service: the extra component may not justify its operational cost.

Interview questions

• What is the difference between a forward and a reverse proxy? A forward proxy represents clients and hides them from servers. A reverse proxy represents servers and hides them from clients.
• Why terminate TLS at the proxy? It centralizes certificates and offloads cryptographic work from backends, and it lets the proxy inspect HTTP for routing and filtering. Internal links can be re-encrypted where needed.
• How is an API gateway different from a load balancer? A load balancer distributes traffic across interchangeable instances. A gateway routes between different services and applies API policies such as authentication, quotas, and transformation.
• What are the risks of putting business logic in the gateway? It becomes a shared, frequently changed component that couples teams and releases, and a failure or slowdown affects every service.