Load Balancer vs. API Gateway

A load balancer and an API gateway can both sit at the edge of a system, but they solve different problems.

A load balancer spreads traffic across multiple backends so one instance does not take all the requests. Its job is availability and distribution. An API gateway sits in front of APIs and applies application-level policies such as authentication, rate limiting, request routing, and protocol transformation.

The easiest way to separate them is by the question they answer.

• A load balancer answers: which backend should receive this connection or request?
• An API gateway answers: should this API request be allowed, and how should it be handled before it reaches the service?

A load balancer usually works at Layer 4 or Layer 7.

• A network load balancer deals with TCP, UDP, IP addresses, and ports. It is fast and simple because it does not need to understand HTTP semantics.
• An application load balancer understands HTTP enough to route by host, path, or header, terminate TLS, and perform health checks with richer rules.

Even an application load balancer is still focused on routing and availability. It normally does not become the central place for identity policy, per-client quotas, request rewriting, or API product concerns.

That is where an API gateway fits. A gateway commonly provides:

• authentication and token validation
• authorisation checks or policy hooks
• rate limiting and quota enforcement
• request and response transformation
• protocol bridging, such as HTTP to gRPC or REST aggregation
• API keys, developer onboarding, and usage analytics
• version-based routing and deprecation controls

This difference affects the services behind the edge. Without a gateway, each service often implements more of its own cross-cutting concerns. That can be flexible, but it also duplicates security logic and rate-limiting code across teams. With a gateway, those concerns can be centralised, which improves consistency and speeds up onboarding for new services.

The tradeoff is concentration of responsibility. A gateway becomes a policy choke point and a potential latency bottleneck. If it performs heavy auth checks, body transformation, or fan-out aggregation, it can be harder to scale and troubleshoot than a simpler load balancer. Teams also need to avoid pushing too much business logic into the gateway, or it turns into a fragile mini-platform.

In production, the two components are often used together. A common setup is internet traffic reaching a CDN or WAF first, then a load balancer, then one or more API gateway instances, and finally the backend services. Another setup uses only a load balancer because the services themselves already handle auth, quotas, and routing policy. That is often enough for smaller systems.

The operational constraint is to match the edge layer to the actual problem. If the problem is backend instance health, connection distribution, and failover, use a load balancer. If the problem is API control, client identity, traffic policy, and consistent edge behaviour, use an API gateway. If both problems exist, combine them, but keep the responsibilities clean so the gateway does not become a hidden monolith at the edge.