API gateway vs reverse proxy

A subtle but real distinction

Both sit in front of your servers and forward requests, so where’s the line? It’s how much they understand. A reverse proxy moves traffic; an API gateway manages an API surface. Every API gateway is a reverse proxy — but not every reverse proxy is a gateway.

Reverse proxy — forward and offload

A general-purpose intermediary focused on network-level concerns:

• Load balancing, TLS termination, caching, compression, static-file serving, basic path/host routing.
• It largely doesn’t care about who the caller is or what the API means — it forwards efficiently.
• Examples: Nginx, HAProxy (in their basic role).

API gateway — manage the API

A specialized reverse proxy focused on application/API-level concerns:

• Authentication & authorization per client/route.
• Rate limiting & quotas per consumer.
• Routing by API semantics — version, path, client tier.
• Request aggregation / composition, transformation, protocol translation (e.g. REST↔gRPC).
• API-centric observability, billing, developer keys.
• Examples: Kong, AWS API Gateway, Apigee.

The side-by-side

So which do you put in a design?

• Reverse proxy is enough when you just need TLS, caching, and load balancing in front of a service or two.
• API gateway earns its place when you expose many services or a public API and need centralized auth, per-client rate limiting, and request aggregation.

Adding a gateway buys management and control at the cost of more complexity and another hop — don’t reach for it if a reverse proxy covers the need.

The interview cue

“Behind the load balancer I’d use a plain reverse proxy if it’s one service. But since we’re exposing a public API across several services, I’ll use an API gateway for centralized auth, per-client rate limiting, and aggregation — accepting the extra hop and making it redundant.” Drawing the line at API awareness — and not over-reaching for a gateway you don’t need — is the signal.