Side by side
| Dimension | API gateway | Load balancer |
|---|---|---|
| Primary role | Enforce API policies and route requests | Distribute traffic across healthy targets |
| Protocol awareness | Usually understands HTTP APIs and RPC methods | L4 connections or L7 HTTP requests |
| Routing | API routes, versions, and client policies | Backend pools; L7 can route by host or path |
| Authentication | Often validates credentials or tokens | Varies; some L7 products support authentication |
| Rate limiting | Often supports per-client or per-tenant quotas | May offer traffic limits; capabilities vary |
| Request handling | May transform or aggregate API requests | Primarily forwards traffic; L7 may rewrite headers |
| Backend selection | Can balance upstream traffic itself | Core function, with health checks and draining |
| Operational concern | Policy dependencies and configuration complexity | Health detection, capacity, and connection handling |
The differences that matter
These are overlapping roles, not mutually exclusive device categories. An L4 load balancer chooses targets using transport-level information, while an L7 load balancer can inspect HTTP hosts and paths. A gateway typically adds API policies on top of reverse proxying and may already include upstream load balancing.
Routing to a service and selecting an instance are separate decisions. A gateway might map /orders to the order service, then select an instance through service discovery or forward to an internal load balancer. Add that internal load balancer only if it solves a concrete discovery, health-checking, or operational need.
A gateway can validate tokens and enforce client quotas before requests reach application servers. Services still need resource-level authorization, such as checking whether a caller owns an order. Distributed quotas also need an explicit state model: independent counters on gateway replicas do not automatically enforce one account-wide limit.
Every separate proxy layer adds processing, connections, configuration, and another possible failure point. Gateway policies may also depend on identity or quota services, so define timeouts and fail-open versus fail-closed behavior. For either role, discuss redundant instances, health checks, connection draining, and bounded retries rather than assuming the box guarantees availability.
Choose API gateway when
- Multiple APIs need consistent token validation, client identification, or per-tenant quotas at the entry point.
- Public clients need a stable API while internal service routes or API versions change.
- You need deliberate request or response transformations, without pushing substantial business logic into the gateway.
- Different endpoints need different admission policies, such as stricter limits for login attempts or expensive searches.
Choose Load balancer when
- You are distributing traffic across replicas of one service and do not need centralized API policies.
- You need L4 balancing for TCP or UDP traffic rather than HTTP API processing.
- Authentication and quota enforcement already live elsewhere, so another policy layer would duplicate responsibility.
- You need an entry point for gateway replicas, or an internal balancing layer with a clearly defined health-checking and discovery role.
A worked example
A shared quota across four gateway replicas
Suppose a public order API receives 20,000 requests per second and requires a sustained limit of 100 requests per second per merchant. A load balancer can spread requests across four gateway replicas, but it does not by itself provide that merchant-level quota. The gateways validate tokens, identify merchants, and route accepted requests to order-service instances. If each gateway independently allows 100 requests per second for the same merchant, the combined sustained allowance can reach 400. Choose shared atomic quota state, partition enforcement by merchant, or explicitly accept an approximate limit. If the application already performs these checks and exposes one API, a load balancer alone may be sufficient.
In the interview
- Name the responsibility before naming the component: distributing traffic, routing APIs, validating identity, or enforcing quotas. An interviewer may ask whether one proxy can cover all required roles.
- Draw the request path and explain every hop. A possible layout is client → load balancer → gateway replicas → services, but it is not a mandatory template.
- Explain how replicas discover healthy upstreams and how deployments drain existing traffic. Expect follow-ups about long-lived connections, stale health information, and uneven request costs.
- State where policy data lives and what happens when it is unavailable. Expect probes about quota consistency, token revocation, timeout budgets, and retry safety.
Common mistakes
- Claiming load balancers cannot inspect HTTP paths or support authentication. L7 capabilities overlap with gateways and vary by product.
- Drawing both components automatically without explaining which responsibility each owns.
- Treating gateway authentication as sufficient authorization for every resource and operation.
- Configuring retries or rate limits independently at several layers without accounting for retry amplification or multiplied quotas.
Where it comes up
Interview questions where choosing between API gateway and Load balancer comes up.
- Design a distributed rate limiterGateway placement makes client identification, shared quota state, and failure behavior concrete.
- Design a login and authentication systemThe design must distinguish gateway token validation from session revocation and service-level authorization.
- Design a ticket booking system like TicketmasterFlash-sale traffic requires separating load distribution from admission control that protects scarce-inventory operations.
- Design a chat app like WhatsAppLong-lived connections expose the limits of request-based balancing and require explicit connection routing and draining.
Questions people ask
Can an API gateway replace a load balancer?
It can replace a separate upstream load balancer if it supports the target discovery, balancing, and health checks you need. You still need a way to direct clients to healthy gateway replicas, which may involve a managed endpoint, load balancer, or DNS-based routing.
Does a load balancer go before or after an API gateway?
Either placement can make sense. A load balancer before the gateway distributes traffic across gateway replicas; one after it distributes traffic across service instances. You may not need the second layer if the gateway already handles upstream discovery and balancing.
Is an API gateway the same as an L7 load balancer?
No, but their capabilities overlap. An L7 load balancer routes HTTP requests and distributes them across targets, while a gateway emphasizes API policies such as identity checks, quotas, and transformations. Compare required capabilities rather than relying on product labels.