API Gateway & Reverse Proxy

1. What Is It?

A reverse proxy is a server that sits between clients and backend servers, forwarding requests on behalf of clients. It provides SSL termination, caching, compression, and load balancing — the backend servers see only the proxy's IP, not the client's. A reverse proxy is infrastructure-level: it routes HTTP traffic.

An API gateway is a superset: it does everything a reverse proxy does, plus adds authentication/authorization, rate limiting, request transformation, analytics, versioning, and protocol translation. It's the single entry point for all external API clients. An API gateway is application-aware — it understands API contracts, not just HTTP traffic.

The relationship: every API gateway is a reverse proxy, but not every reverse proxy is an API gateway. The distinction matters in interviews because they solve different problem classes: reverse proxy for scaling and SSL offload; API gateway for API lifecycle management, security, and microservices coordination.

2. How It Works

Reverse Proxy Core Functions

A reverse proxy receives requests from clients and forwards them to one or more backend servers:

Client → Reverse Proxy → Backend Server(s)
                         ↑ client only sees the proxy's IP

SSL Termination: The proxy decrypts HTTPS from clients, forwards plain HTTP to backends. Centralizes certificate management; offloads TLS CPU from application servers.

Caching: Cache responses from backends. On cache hit, serve from proxy memory/disk — backend is not called. Reduces backend load and improves response time for repeated requests.

Compression: Apply gzip/brotli compression at the proxy layer. Application code doesn't need to handle it.

Static file serving: Serve images, JS, CSS directly from the proxy's disk, bypassing the application server entirely.

Buffering: Buffer slow client connections so backends can respond quickly and move on, instead of being held waiting for slow clients to receive data.

API Gateway Capabilities (Superset of Reverse Proxy)

Client (web/mobile) → [API Gateway] → Microservice A
                                    → Microservice B
                                    → Microservice C (aggregated response)

Auth Offloading Pattern

Without API Gateway:
  Every microservice must:
  1. Accept JWT token
  2. Validate signature
  3. Check expiry
  4. Parse claims
  5. Authorize the specific operation
  → Auth logic duplicated across all services

With API Gateway:
  Gateway:
  1. Validates JWT signature + expiry
  2. Extracts claims (user_id, roles)
  3. Injects claims as headers: X-User-Id, X-User-Role

  Microservice:
  1. Trusts headers from gateway (network boundary = trust boundary)
  2. Only does fine-grained resource-level auth (can this user_id access this specific resource?)
  → Auth logic centralized; services focus on business logic

WHY: Centralizing auth at the gateway is simpler to maintain (one place to update auth logic) but requires trusting the internal network. Fine-grained authorization (can user X access resource Y?) must still live in each service — the gateway can't know the business rules of every microservice.

Request Aggregation / Fan-Out

-+ResetFullscreen

This pattern reduces mobile client chattiness — on a 150ms latency mobile connection, making 3 serial requests adds 450ms; 1 aggregated request adds 150ms + max(backend latency).

Mermaid: Full API Gateway Architecture

-+ResetFullscreen

BFF (Backend for Frontend) Pattern

Instead of one general-purpose gateway for all clients, create a separate gateway per client type:

-+ResetFullscreen

WHY BFF: A single API gateway becomes a "lowest common denominator" API that tries to satisfy all clients. Mobile clients need smaller payloads; web clients need richer data; partner APIs need specific contracts. BFF lets each team own their gateway layer and evolve independently.

API Gateway vs Service Mesh

3. Variants & Comparisons

API Gateway Products

REST API Gateway vs GraphQL Gateway

4. When to Use It (and When NOT To)

Use an API Gateway When:

• Microservices architecture: Multiple backend services need a unified entry point. Auth, rate limiting, and logging shouldn't be duplicated in every service.
• Centralized auth: Validate JWT/OAuth tokens once at the gateway; inject user identity as trusted headers downstream. Avoids auth logic in every service.
• Different API versions in production: Route /v1/ and /v2/ to different backends simultaneously during migration. Zero-downtime versioning.
• Protocol translation: External clients use REST/HTTP; internal services use gRPC. The gateway translates.
• Canary deployments: Route 5% of traffic to new service version, 95% to old. Gradual rollout with automatic rollback on error rate spike.
• Rate limiting by API key: API products with free/paid tiers. Gateway enforces limits without touching service code.

Use a Reverse Proxy Only When:

• Single backend service (monolith): A full API gateway is overkill. Nginx as a reverse proxy for SSL termination, caching, and load balancing is sufficient.
• Static site + API backend: Nginx serves *.js, *.css files directly; proxies /api/* to the application server. No need for a full API gateway.
• Simple SSL termination: You just need HTTPS → HTTP conversion. Nginx or an ALB handles this.

Do NOT Use an API Gateway When:

• Internal service-to-service calls: An API gateway is for external (north-south) traffic. Service A calling Service B internally should use direct HTTP/gRPC + service discovery (Consul, Kubernetes DNS), not go through an external API gateway.
• You haven't outgrown a monolith yet: API gateways introduce complexity (another service to deploy, manage, and tune). For a monolithic app with one backend, a simple Nginx reverse proxy is simpler and more reliable.
• Latency-critical paths where gateway overhead matters: An API gateway adds 5–20ms per request (auth validation, plugin execution, logging). For sub-10ms P99 requirements, measure and consider gateway bypass for hot paths.

5. Real-World Usage

Netflix — Zuul (API Gateway)

Netflix built and open-sourced Zuul as their API gateway. By 2013, Zuul was handling 2 billion daily API requests from external Netflix clients (iOS, Android, web, Smart TVs, gaming consoles) to 500+ internal microservices. Zuul's key features: dynamic filters (written in Groovy, deployed without restart), request routing, authentication, and deep integration with Hystrix (circuit breaker). Netflix eventually moved to Zuul 2 (async, non-blocking) and later adopted Zuul alongside other gateway implementations.

Kong (Open-Source)

Kong powers API gateways for thousands of enterprises. Built on Nginx + OpenResty (Lua), it provides a plugin architecture where each cross-cutting concern (auth, rate limiting, logging, transformation) is an independent plugin. Kong can handle hundreds of thousands of requests/second on commodity hardware. The plugin ecosystem (100+ official + community plugins) makes it the most flexible self-hosted API gateway.

AWS API Gateway + Lambda (Serverless Pattern)

The AWS API Gateway + Lambda pattern is the dominant serverless API architecture: API Gateway handles routing, auth (via Cognito Authorizer or Lambda Authorizer), throttling, and CORS; Lambda functions implement the business logic. No servers to manage. HTTP APIs (newer, lighter) are up to 71% cheaper than REST APIs for simple proxy scenarios.

6. Interview Cheat Sheet

5 Sentences to Show Deep Understanding

1. "An API gateway is a reverse proxy plus API management: it adds authentication, rate limiting, request transformation, aggregation, and analytics to the raw proxying capabilities of Nginx/HAProxy — the key insight is centralizing cross-cutting concerns that would otherwise be duplicated in every microservice."

2. "Auth offloading at the API gateway is powerful but incomplete: the gateway handles authentication (is this request from a valid user?) and coarse-grained authorization (is this API key allowed to call /payments?), but fine-grained authorization (can this user access this specific resource?) must stay in the individual service — the gateway can't know every service's business rules."

3. "BFF (Backend for Frontend) solves the 'lowest common denominator API' problem: instead of one general-purpose gateway that returns too much data to mobile clients and too little to web clients, you create separate gateways per client type, each evolving independently."

4. "API gateways handle north-south traffic (external → internal); service meshes handle east-west traffic (service A → service B internally). They are complementary: the gateway secures the perimeter, the service mesh secures and observes internal communication — you often need both at scale."

5. "Request aggregation at the gateway reduces mobile client chattiness: instead of a mobile app making 3 serial API calls over a 150ms-latency connection (450ms total), the gateway fans out to 3 services in parallel and returns one merged response (150ms + max backend latency)."

Common Follow-Up Questions

Q: What are the drawbacks of an API gateway? A: (1) Single point of failure: If the gateway goes down, all external traffic is blocked. Mitigate with multiple instances behind a load balancer and health checks. (2) Latency overhead: Each plugin (auth, rate limit, logging) adds overhead — 5–20ms typically. (3) Bottleneck at scale: The gateway must handle all external traffic; it needs horizontal scaling and caching. (4) Tight coupling: Services may start to depend on gateway-injected headers or behaviors, creating implicit coupling.

Q: How do you handle authentication in a microservices system? A: Three-layer approach: (1) API Gateway validates the JWT signature and expiry, extracts claims (user_id, roles), and injects them as trusted headers (X-User-Id, X-Roles). (2) Services trust these headers within the internal network (the gateway is the trust boundary). (3) Each service still does fine-grained authorization — "can user 123 read order 456?" — based on its own data and business rules. NEVER trust user-supplied identity headers from outside the gateway.

Q: What is the difference between an API key and a JWT? A: An API key is an opaque secret — the gateway must look it up in a database to validate it and find associated permissions (database call on every request). A JWT is self-contained — it carries signed claims, and the gateway validates the signature locally using a public key (no database call). JWTs are better for high-scale APIs; API keys are simpler for server-to-server partner integrations where the key doesn't change often.

Q: How would you do a zero-downtime version migration at the API gateway? A: Route by path prefix (deploy v2 alongside v1): /v1/* → old service, /v2/* → new service. Both run simultaneously. Clients opt into v2 when ready. When v1 traffic drops to zero (or a deadline passes), decommission the v1 route. For canary: use weighted routing — route 5% of /v2/* traffic to new backend, 95% to stable backend. Monitor error rates; ramp to 100% if healthy.

Connections to Other Building Blocks

• Load Balancing: The API gateway distributes requests across backend instances (it's an L7 load balancer plus more). The gateway sits behind a L4 load balancer for high availability.
• Rate Limiter: Rate limiting is one of the most common API gateway plugins. The gateway is the enforcement point (Redis-backed, per-API-key counters).
• Circuit Breaker: API gateways (Kong, Envoy) have circuit breaker plugins that stop forwarding to failing backends and return cached responses or error messages.
• Caching: API gateways cache responses at the gateway layer (e.g., Kong's Response Caching plugin), reducing load on backends for repeated identical requests.
• Service Mesh (Envoy/Istio): API gateway handles external north-south traffic; service mesh handles internal east-west traffic. They complement each other.
• CDN: CDN handles static asset delivery at the edge; API gateway handles dynamic API traffic. Both sit in front of backends, but at different layers of the stack.