Load Balancer vs Proxy vs API Gateway

Load Balancer vs Reverse Proxy vs API Gateway

A load balancer distributes traffic across destinations. A reverse proxy receives requests on behalf of backend services. An API gateway adds a managed API-facing policy and routing surface. These are overlapping responsibilities: one product can perform several, and an architecture does not automatically need three separate hops.

Choose components from the requirements: protocols, traffic distribution, API policies, trust boundaries, and operational ownership. Product labels are a useful starting point; the configured behavior is the part your requests actually encounter.

TL;DR

Use load balancing to select among backend instances, with an explicit failure-detection and connection model.
Use a reverse proxy to mediate backend access and HTTP behavior such as routing or header handling.
Evaluate an API gateway when you need consistent API policies, consumer-facing management, or supported API integrations.
Distinguish transport-level traffic handling from HTTP-aware routing; inspect the actual product and configuration.
Combine roles when one component meets the requirements; split them when boundaries or ownership justify another layer.
Preserve resource authorization in the application and test timeouts, retries, path handling, and failure behavior across the full chain.

Quick Example

This complete local HTTP demonstration configuration shows one NGINX instance acting as both a reverse proxy and a load balancer. It assumes two test HTTP backends already listen on loopback ports 9001 and 9002 and accept paths beginning /api/. It supplies no authentication, TLS, or API consumer management, and is not a public deployment recipe.

Save it as nginx.conf in an existing local NGINX test installation and validate it using that installation's nginx -t -c command with the absolute file path. Required log directories and permissions come from the installation. Then test a request to http://127.0.0.1:8080/api/orders against the two test backends.

The upstream group supplies traffic distribution; proxy_pass supplies proxying. NGINX's HTTP balancing guide documents the default round-robin method. The reverse-proxy guide explains forwarding and header configuration.

Here, proxy_pass has no replacement URI, so /api/orders remains /api/orders. The forwarded-address header is overwritten with the direct peer address for this single local hop. That is not a trusted-client-address policy for an arbitrary chain of proxies. Retry is disabled so this teaching example does not silently replay a request; production retry policy needs its own application-level design.

Core Concepts

Load balancing describes destination selection

A balancer selects where traffic goes among a set of destinations. At the transport layer, selection concerns connections or flows. At the HTTP layer, it can use request-aware information and policies. NGINX documents TCP/UDP balancing separately from its HTTP balancing behavior.

Do not infer that every component named “load balancer” only understands IP addresses and ports. Likewise, selecting an HTTP balancer does not establish that it provides every API management feature your organization needs.

Reverse proxying describes mediation for backends

An HTTP reverse proxy accepts a client request, forwards it to a backend, and returns the response. It can also handle routing, headers, buffering, or TLS termination when configured to do so. It can proxy to one backend or balance among several.

This is why “proxy or load balancer?” can be the wrong choice. The local example is both. Describe which behavior you need and at which layer instead of assuming the labels identify mutually exclusive appliances.

API gateways provide an API-facing policy surface

An API gateway commonly combines API routing with capabilities such as authentication integrations, traffic policy, monitoring, or API lifecycle management. Features vary by implementation and API type. As one product example, Amazon API Gateway's introduction describes API creation, traffic handling, access mechanisms, and integrations.

Treat a product's supported protocols and policies as configuration-specific facts. “API gateway” does not guarantee every feature for every API type, nor require a microservice architecture. A single backend can still have several consumers with useful shared API policies.

Compare responsibilities before choosing products

Our selection recommendation is to map these requirements to the smallest supported component set. This is editorial guidance, not evidence that any one vendor will reduce cost or latency in every deployment.

Trace a request through two valid architectures

One component handles proxying and balancing

For a hypothetical internal application with two replicas, one supported HTTP proxy may provide the required routing and distribution. The operator still needs redundancy for the proxy layer if its failure must be tolerated. Two healthy backends cannot compensate for a single unavailable entry point.

Keep the design modest when its requirements are modest. Before adding another service, identify a policy or failure boundary the existing component cannot adequately provide. A diagram with more boxes also has more configuration, telemetry, upgrades, and failure modes to maintain.

Separate layers serve different boundaries

Another system may place an external traffic-distribution layer before a gateway fleet, then use internal balancing to reach application replicas. This can be appropriate when external connectivity, API policy, and service operation have different ownership or scaling requirements.

There is no universal ordering rule. A managed gateway may hide some of these layers; a self-operated gateway fleet may need an explicit entry point. Trace the actual request from client to service. Mark where TLS ends, where identity is established, which headers are trusted, and which destination-selection decisions occur.

Choose another hop when it resolves a concrete requirement and the team can operate it. Reconsider when it duplicates a policy inconsistently, obscures failures, or forces unsupported behavior. The goal is a request path you can explain and diagnose.

Design behavior at the seams

Preserve paths intentionally

In NGINX, adding a URI to proxy_pass can replace the matching location prefix. The proxy module reference defines the behavior and its conditions. Test the exact path, query string, redirects, and any prefix that the backend expects.

A proxy configuration that returns a page at / may still break /api/orders or an application-generated redirect. Include nested paths and failure responses in verification rather than stopping at a successful health check.

Budget timeouts and retries together

Separate connection establishment, waiting between response reads, and the application's overall deadline. For example, NGINX's proxy_read_timeout concerns time between successive reads, not a guaranteed total request duration. Do not label the example's five-second setting as an end-to-end deadline.

Retries can multiply across layers. In a fictional chain where a gateway permits two total attempts and each reaches a proxy permitting three total attempts, the configured upper bound can be six backend attempts for one incoming request. That arithmetic is illustrative, not a measured product outcome. The actual count depends on eligible failures, methods, remaining deadlines, and implementation.

Do not automatically replay non-idempotent work because a connection failed after the backend may have acted. The NGINX reference documents conditions for retrying and special treatment of non-idempotent methods. Application-level duplicate prevention and a deliberate policy are separate from choosing a balancer.

Keep identity and authorization boundaries intact

A gateway can verify a credential or apply an API-level policy, but a backend must still enforce the authorization required for the resource and action. OWASP's authorization guidance calls for checking permissions on every request and placing those checks correctly.

If a service trusts identity propagated from a gateway, define an authenticated, protected path and prevent clients from supplying equivalent trusted assertions directly. Review bypass routes, header handling, and internal callers. An HTTP header name is not proof of identity.

Best Practices

Own each policy once, then document enforcement

For authentication, rate limits, body limits, caching, and retries, identify the policy owner and every enforcement point. Multiple enforcement points can be intentional; conflicting undocumented defaults are harder to diagnose.

Test failure, recovery, and draining

Check what happens when a backend stops accepting connections, returns an error, becomes slow, or is removed during a long request. Passive failure detection and active health checks are different mechanisms. Verify what your product and edition actually implement.

Follow one request across all hops

Use an agreed correlation and tracing approach with a trust policy for incoming identifiers. Record where a rejection or timeout happened. Avoid logging credentials or sensitive payloads just to make troubleshooting convenient.

Common Mistakes

Requiring three boxes for three names

Bad: Add a load balancer, reverse proxy, and gateway without identifying separate requirements.

Correct: Map responsibilities to supported capabilities, then add layers only for a clear boundary, operating need, or missing function.

Treating authentication as resource authorization

Bad: Let a valid gateway-authenticated request access any record identifier.

Correct: Preserve the service's tenant, resource, and action checks using trusted identity and authoritative data.

Retrying every failure at every layer

Bad: Increase retries independently wherever a timeout appears.

Correct: Review the whole attempt and deadline budget, method semantics, and duplicate handling. Test the failure path before enabling retries.

FAQ

Is a reverse proxy the same as a load balancer?

They describe different responsibilities that can overlap. An HTTP proxy with an upstream group can perform both, as the local example shows. Inspect the configuration and layer rather than treating the names as equivalents.

Which comes first: the API gateway or load balancer?

It depends on the deployment. A gateway fleet may sit behind an external balancer and use another balancing mechanism for services. A managed gateway may abstract those details. Draw the actual traffic flow.

Do I need a gateway for one backend?

Possibly, if shared API policy or consumer management justifies it. Backend count alone is not the deciding factor. Start with the required capabilities and their operating cost.

Does a gateway make the API secure?

It can enforce selected controls when correctly configured. Application authorization, trusted identity propagation, transport protection, and bypass prevention still require an explicit design and review.