What an API Gateway and a Reverse Proxy Actually Do at the Protocol Level
When a request arrives at your infrastructure, two distinct questions need answering: which server should handle this connection, and whether the caller is authorized, correctly shaped, and compliant with the consumer contract. Conflating the tools that answer those questions produces architectures that are either over-engineered or under-secured. Knowing exactly where each tool operates at the protocol level is what determines whether you deploy one, the other, or both in a layered configuration.
Nginx and HAProxy are among the most widely deployed reverse proxies in production infrastructure. Kong, AWS API Gateway, and Apigee are the commonly cited examples on the gateway side. The distinction matters because the feature sets these tools expose correspond to entirely different operational concerns.
- Reverse proxy core function: forwards client requests to a pool of backend web servers using load-balancing algorithms like round-robin or least-connections, hiding server identity from the client. This is a network-level routing capability, full stop.
- SSL/TLS termination: the reverse proxy decrypts HTTPS traffic at the edge and forwards plain HTTP to backend servers, offloading cryptographic overhead from application code. A straightforward infrastructure efficiency win.
- Caching and compression: reverse proxies like Nginx can cache static responses and gzip-compress payloads before delivery, reducing origin bandwidth by a measurable percentage in high-traffic deployments.
- API gateway authentication: an API gateway validates OAuth 2.0 tokens, API keys, or mutual TLS certificates before a request touches any microservice, centralizing auth logic that would otherwise be duplicated across dozens of services. This is application-level security enforcement, and it lives at a completely different layer than what a reverse proxy touches.
- Request transformation and orchestration: API gateways like Kong or Apigee can rewrite request headers, translate between REST and gRPC, aggregate responses from multiple upstream microservices into a single client response, and enforce per-consumer rate limits measured in requests per second. No standard reverse proxy does this natively. That gap is the whole point.
Why the Distinction Shapes Real Architecture and Tooling Decisions
Most production microservices architectures end up running both tools in a layered configuration. Seeing why requires tracing what happens when a monolith decomposes. In a monolithic application served by two or three web servers, a reverse proxy is sufficient: Nginx sits in front, load-balances across three Node.js instances, terminates TLS, and serves cached static assets. The moment that monolith decomposes into separate billing, user, inventory, and notification services, the reverse proxy's feature set stops being adequate. None of those services should independently re-implement rate limiting, token validation, or request logging. That's not a minor inconvenience, it's a maintenance disaster waiting to happen.
Some practitioners frame this as an API gateway being the front door to your underlying APIs and a reverse proxy being the front door to your web applications. The practical consequence: a reverse proxy like Nginx or an edge CDN handles network-level concerns at the perimeter, and an API gateway like Kong or AWS API Gateway handles API lifecycle management one layer deeper.
- Rate limiting granularity: an API gateway enforces rate limits per API key, per consumer plan, or per endpoint. A reverse proxy can only rate-limit by IP address or connection count. In a multi-tenant SaaS product, that gap in consumer-level policy enforcement is not a minor omission.
- Observability output: API gateways emit structured telemetry including latency per route, error rate per upstream service, and quota consumption per API key, giving platform teams the data needed for SLA reporting. Standard reverse proxy access logs don't come close to replicating this.
- Protocol translation: Kong and AWS API Gateway can accept a REST request from a mobile client and forward it as a gRPC call to an internal Go service, abstracting the internal protocol from external consumers entirely. Reverse proxies don't offer this out of the box.
- Developer portal integration: commercial gateways like Apigee and Azure API Management bundle developer portals, API versioning controls, and usage dashboards into the same product, making the gateway a product management surface as much as a traffic management tool.
- Operational cost tradeoff: deploying a full API gateway adds configuration complexity and a non-trivial latency budget, which can vary considerably per hop depending on plugin load. Teams running simple CRUD services sometimes pay this cost for no real benefit.
The architecture advice that holds up in practice: reach for a reverse proxy first, and introduce an API gateway only when you have multiple independent services sharing cross-cutting concerns like authentication, rate limiting, or contract versioning. Deploying Kong or AWS API Gateway in front of a single-service backend pays the complexity cost of microservices tooling without any of the distribution benefit. On the other end, relying on Nginx alone to manage a 20-service Kubernetes deployment means scattering auth logic, rate-limit logic, and observability instrumentation across every service's codebase. That's precisely the problem API gateways exist to solve. The opening question, which server and whether authorized, only has a clean answer when the tool choice follows the architecture shape rather than preceding it.