Forward Proxy vs Reverse Proxy

The word 'proxy' alone is ambiguous. The distinction is which side it represents.

Forward proxy

Sits in front of clients. Clients send requests through the proxy, which forwards them to the internet. Examples: corporate web filters, residential VPNs, a Squid cache for a school network.

Reverse proxy

Sits in front of servers. Clients connect to the proxy thinking it is the server. The proxy forwards the request to the actual backend. The client never sees the backend's IP.

---------- Forward vs reverse proxy ----------
  Forward proxy (per-client):                                                  
    [ user 1 ] -> [ corp proxy ] -> [ open internet ] -> [ external sites ]    
    [ user 2 ] -> [ corp proxy ]                                               
                                                                               
  Reverse proxy (per-server-fleet):                                            
    [ user ] -> [ reverse proxy ] -> [ b1 ] [ b2 ] [ b3 ]

The rest of this lesson is about reverse proxies.

What a Reverse Proxy Does

A reverse proxy is the right place for any concern that is the same across every backend.

1. TLS termination

The proxy holds the TLS certificate; the client negotiates HTTPS with the proxy; the connection from proxy to backend is plain HTTP (or mTLS inside the cluster). Backends do not need their own certificates, do not pay the TLS handshake cost, and are not exposed publicly.

---------- TLS termination at the edge ----------
  client - HTTPS (TLS 1.3) --> [ reverse proxy ] - HTTP --> [ backend ]

2. Compression

The proxy gzips or brotlis responses before sending them to the client. Backends emit raw responses; the proxy compresses once. Saves backend CPU; centralizes the compression policy.

3. Response caching

For cacheable responses (per Cache-Control headers), the proxy stores them and serves subsequent requests from cache without touching the backend. NGINX, Varnish, and Cloudflare all do this.

4. Request buffering

A slow client sending a 10 MB body byte-by-byte would tie up a backend worker for minutes. The proxy buffers the entire request in memory or on disk and only forwards it to the backend once complete. Same in reverse for slow clients reading responses.

5. IP allowlists / blocklists, geo-blocking

The proxy is the natural place to drop traffic from unwanted IP ranges, abusive ASNs, or sanctioned countries.

6. Header manipulation

Add X-Forwarded-For, X-Request-ID, security headers (Strict-Transport-Security, Content-Security-Policy); strip server-internal headers from responses.

NGINX example: reverse proxy with TLS termination and gzip

---------- NGINX reverse proxy ----------
server {
    listen 443 ssl http2;
    server_name api.example.com;
    ssl_certificate     /etc/ssl/api.example.com.crt;
    ssl_certificate_key /etc/ssl/api.example.com.key;

    gzip on;
    gzip_types application/json text/html;

    location / {
        proxy_pass http://backend_pool;
        proxy_set_header X-Forwarded-For  $remote_addr;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header Host             $host;
    }
}

That is the canonical reverse-proxy config. Most websites' edge starts here.

API Gateway: Reverse Proxy with Opinions

An API gateway is a reverse proxy with first-class support for the cross-cutting concerns specific to APIs. Think of it as 'reverse proxy + auth + per-route policy + transformation'.

Capabilities a gateway adds

Architecture diagram

---------- API gateway in front of microservices ----------
  client - HTTPS --> [ API gateway ]
                          |  - TLS termination
                          |  - JWT validation
                          |  - rate limiting
                          |  - request rewriting
                          v
     +---------+---------+---------+----------+
     v         v         v         v          v
  [ users ] [ orders ] [ catalog ] [ search ] [ payments ]

Each service is small, language-agnostic, and free of auth/rate-limit boilerplate. The gateway is the single declarative description of every public API.

Per-route policy example (Kong style YAML)

routes:
    - name: list-orders
      paths: ['/v1/orders']
      methods: ['GET']
      service: orders
      plugins:
          - name: jwt
            config:
                key_claim_name: kid
          - name: rate-limiting
            config:
                minute: 60
                policy: redis
          - name: response-cache
            config:
                ttl: 30

Readable and reviewable; no application code changes needed to add or change a policy.

Backend-for-Frontend (BFF)

A BFF is an API gateway tailored to a specific client (web, mobile, partners). The same backends serve all clients, but each gateway transforms responses and aggregates requests differently.

---------- BFF pattern ----------
  [ web app ] -> [ web BFF ]    -> orders, users, catalog
  [ iOS app ] -> [ mobile BFF ] -> orders, users, catalog (smaller payloads, image variants)
  [ partner ] -> [ partner BFF ] -> orders only (rate-limited to 100/min)

Not every system needs BFFs - they add operational surface - but for products with multiple very different clients (Spotify, LinkedIn), it is a clean way to keep core services general while each client gets a tailored interface.

Edge vs Service: Where Logic Belongs

The most important judgment call in any gateway design is the boundary: what lives at the edge, what stays in the service?

At the edge (gateway)

• Authentication (JWT validation, mTLS)
• Coarse authorization (scope check)
• Rate limiting per API key
• Request shaping (path rewrite, header rewrite)
• TLS, compression, response caching
• Cross-cutting observability

These concerns are the same regardless of which service handles the request. Centralizing them eliminates duplication.

In the service

• Business logic
• Fine-grained authorization ('can user 42 edit document 99?')
• Domain-specific validation
• Workflow orchestration (when complex enough)
• Per-tenant data partitioning

These concerns require domain knowledge; the gateway should not know what a document is.

The fat-gateway anti-pattern

When the gateway starts knowing about business rules ('the orders gateway aggregates inventory + pricing + cart + recommendations and applies a coupon'), you have re-created a monolith with a different name. Now every product change requires gateway changes; the gateway team becomes a release bottleneck; backend services lose autonomy.

The rule: the gateway transforms requests; it does not understand them. If you find yourself adding domain logic to the gateway, that logic belongs in a backend service or a dedicated 'aggregator' service that itself sits behind the gateway.

Tool Selection

Default recommendations:

• Single small service: NGINX is enough.
• Microservices on Kubernetes: Envoy (Istio/Linkerd as the mesh) or Traefik.
• Public API for paying customers: Kong (self-hosted) or AWS API Gateway / Apigee (managed).
• DDoS / WAF / global cache: put Cloudflare in front of any of the above.

Routing in Action: A Request's Journey

Follow a real request from browser to database through a typical gateway-fronted system.

---------- Request lifecycle ----------
  T0   POST https://api.example.com/v1/orders  (with JWT, body 5 KB)

  T1   Cloudflare edge:                                                            
         - terminates TLS                                                          
         - WAF rule check                                                          
         - origin selection (anycast picks the nearest POP)                        

  T2   Origin reverse proxy (NGINX):                                               
         - terminates the upstream TLS                                             
         - logs the request                                                        
         - forwards to the API gateway                                             

  T3   API gateway (Kong):                                                         
         - validates JWT (cached public key)                                       
         - checks rate limit: 100/min per user-id                                  
         - looks up route '/v1/orders' POST -> orders service                      
         - adds X-Request-ID, X-User-Id headers                                    
         - passes to orders service                                                

  T4   Orders service:                                                             
         - validates body against schema                                           
         - fine-grained auth: user can place order                                 
         - writes order to Postgres                                                
         - emits OrderPlaced event to Kafka                                        
         - returns 201 Created                                                     

  T5   Response travels back the same chain;                                       
       gateway logs duration; proxy compresses; Cloudflare caches if cacheable.

Each layer has one job and is configured independently. Failure of any layer can be retried at the layer above.

Calling a Gateway-Protected API from a Client

async function placeOrder(token, order) {
    const res = await fetch('https://api.example.com/v1/orders', {
        method: 'POST',
        headers: {
            'Authorization': `Bearer ${token}`,
            'Content-Type': 'application/json',
            'X-Idempotency-Key': crypto.randomUUID(),
        },
        body: JSON.stringify(order),
    });
    if (res.status === 429) {
        const retryAfter = Number(res.headers.get('Retry-After') ?? 1);
        await new Promise((r) => setTimeout(r, retryAfter * 1000));
        return placeOrder(token, order);
    }
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return await res.json();
}

Notice the rate-limit handling: the gateway returns 429 with a Retry-After header, and the client respects it. This pattern is enforced at the edge precisely so every backend does not need to implement it.