Dev Skills
Tier 1 — the basics

API gateway vs load balancer vs reverse proxy: what is the difference?

Three names for the box in front of your services. They overlap, and the difference is which job you bought it for.

By devskills editorial team · Last updated

1

What problem do these three components solve?

A reverse proxy receives requests on behalf of your servers and forwards them: it is a front door. A load balancer spreads requests across several copies of the same service. An API gateway manages an API as a product: who may call it, how often, in what shape.

In real systems the three blur together, because one piece of software (NGINX, Envoy, HAProxy, a cloud load balancer) can do some or all of the jobs. The interview question is really asking whether you know which job each box on your diagram is doing, and why it is there.

2

What these three components cost you

What it costs you
Every box in the request path adds a network hop, a configuration you have to get right, and something that must itself be redundant. Stack a CDN, a load balancer, a gateway and a sidecar proxy and you have four hops before your code runs, four places a timeout can be set wrongly, and four teams who can each break every request. The gateway carries a further risk: it is the easiest place to put logic that belongs in a service.
3

When to reach for these three components, and when not to

Use it when

  • Reverse proxy: you want TLS, compression, static files or path routing handled once, in front of any number of backends, even one.
  • Load balancer: you run more than one copy of a service and need traffic spread across them, with unhealthy copies taken out.
  • API gateway: outside clients or many teams call many services, and you need API keys, per-client quotas, authentication and one public surface.

Do not, when

  • Do not add an API gateway to a single service with one client. A reverse proxy or the load balancer you already have does the job.
  • Do not put business rules in the gateway (pricing, which user sees which feature). It becomes a deploy bottleneck no team owns.
  • Do not draw three boxes when one product plays all three roles. Draw one and say what it does.
4

How these three components actually work

httpscache miss/orders/usersClientapp or browserCDNcache at the edgeLoad balancerL4 or L7, health checksAPI gatewayauth, keys, quotasOrders serviceseveral copiesUsers serviceseveral copiesEach arrow from the gateway is itself load balanced, often by a sidecar proxy or the platform
A typical public request path. Each hop has one main job, although a single product can collapse several hops into one.

The one-line answer: a reverse proxy is a role (stand in front of servers), a load balancer is a function (spread load across copies), and an API gateway is a product decision (manage the API for its consumers). Most load balancers and gateways are reverse proxies, so the three are better seen as nested than as rivals.

The reverse proxy terminates TLS, compresses responses, serves static files, routes by host or path and hides your internal layout. It is useful with one backend, which is the quickest way to tell it apart from a load balancer. Our reverse proxy page covers it alone.

The load balancer exists because you run several copies. It picks a healthy copy for each request or connection, using round robin, least connections or a hash, and drops copies that fail health checks. The load balancing page covers the algorithms. What matters here is the layer it works at. A layer 4 load balancer sees TCP or UDP connections: addresses and ports, nothing inside. It is fast and protocol-agnostic, and it cannot route by URL. A layer 7 load balancer reads HTTP, so it can route /api and /static differently, retry a failed request and set headers, at the cost of terminating the connection and parsing every request.

The API gateway is a layer 7 reverse proxy with opinions about APIs. Its usual features are authentication (validating a token or an API key), per-client rate limits and quotas, request and response transformation, routing one public API onto many internal services, and usage analytics per consumer. Some gateways also aggregate, turning one client call into several backend calls. That is the feature most likely to grow into business logic.

One tool, three roles. An NGINX config can terminate TLS, rate-limit by IP and spread requests over an upstream group in the same server block (the example below). Managed cloud products split the roles more firmly: a network load balancer is layer 4, an application load balancer is layer 7, and an API gateway product adds keys, quotas and usage plans. In an interview, name the role, then name the product if asked.

Where each sits. Outside to inside: CDN, then the load balancer that owns the public IP, then the gateway, then the services. Inside the cluster, calls between services (east-west traffic) are balanced by client libraries, the platform or a service mesh sidecar. The gateway is for traffic entering from outside (north-south). A gateway is not a replacement for a load balancer: it needs one in front of it, because the gateway itself runs as several copies.

Backend for frontend (BFF). Instead of one gateway for every client, each client type (web, iOS, partner API) gets its own thin gateway shaped for it, owned by the team that builds that client. It keeps one client's needs from bloating a shared gateway, at the cost of more deployables.

Reverse proxyLoad balancerAPI gateway
Main jobFront door for serversSpread traffic over copies of one serviceManage an API for its consumers
LayerUsually 7 (HTTP)4 (TCP/UDP) or 7 (HTTP)7 (HTTP, gRPC, sometimes WebSocket)
Decides byHost, path, headersHealth, load, a hash of the client or keyWho the caller is, their plan and quota, the route
Typical featuresTLS, compression, caching, static filesHealth checks, algorithms, connection drainingAuth, API keys, quotas, transformation, analytics
Useful with one backend?YesNoOnly if the API has outside consumers
ExamplesNGINX, HAProxy, Envoy, CaddyCloud L4 and L7 load balancers, HAProxy, NGINXKong, cloud API gateway services, Envoy-based gateways
Main riskMisconfiguration affects everythingBecomes a single point of failure if not redundantAccumulates business logic
The three roles side by side. Real products often cover two or three columns at once.
nginx.conf — one box doing all three jobs
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
upstream orders {                  # load balancer: several copies
    least_conn;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
}
server {
    listen 443 ssl;                # reverse proxy: TLS ends here
    server_name api.example.com;
    ssl_certificate     /etc/ssl/api.crt;
    ssl_certificate_key /etc/ssl/api.key;
    location /static/ {
        root /var/www;             # reverse proxy: serve files itself
    }
    location /api/orders/ {
        limit_req zone=perip burst=20 nodelay;   # gateway-style rate limit
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://orders;                # balanced over the upstream
    }
}
This covers rate limiting by IP. Per-customer API keys, quotas and usage plans are where a dedicated gateway starts to earn its place.
Common trap
  • Saying an API gateway replaces the load balancer. The gateway runs as several copies, so something must balance across them.
  • Drawing a gateway, a load balancer and a reverse proxy as three hops when one product does all three.
  • Letting response aggregation in the gateway grow into business logic.
  • Forgetting that layer 4 balancing cannot route by path or retry an HTTP request.
Say this
"One layer 7 load balancer in front, which also terminates TLS. Behind it an API gateway, because partners call us with API keys and need per-key quotas. Each internal service is balanced by the platform. If we only had our own web client, I would drop the gateway and do auth in the services."
5

The follow-up an interviewer will ask about these three components

"Do you need both a load balancer and an API gateway here?"

What a strong answer sounds like

It depends on who calls us. If the only client is our own web app, no: one layer 7 load balancer can terminate TLS, route by path and spread traffic, and the services check the user's token themselves. The gateway would be an extra hop with nothing to do. If outside developers call the API with keys, yes, and here is why each exists. The load balancer owns the public address and keeps traffic flowing to healthy copies, including healthy copies of the gateway. The gateway decides whether this caller may make this call and how many they have left this minute, and it maps one public API onto several internal services. Cost: one more hop, maybe a millisecond or two, and one more component in every request's path, so it needs at least two instances and its own alerts. I would keep it to authentication, quotas and routing, and push anything that looks like a business rule back into a service.

6

Gateway vs LB vs proxy: common questions

Does an API gateway replace a load balancer?

No. Many gateways can balance across backend copies, so inside the cluster they may do that job. But the gateway itself runs as several instances for availability, so you still need a load balancer (or DNS-level balancing) in front of it.

Is NGINX an API gateway?

NGINX is a reverse proxy and load balancer that can do gateway tasks: TLS, routing, rate limiting, basic auth checks. Teams build gateways on it (Kong is built on NGINX via OpenResty). A dedicated gateway adds API keys, per-consumer quotas, a developer portal and analytics without writing them yourself.

What is the difference between a layer 4 and a layer 7 load balancer?

Layer 4 balances TCP or UDP connections using addresses and ports, without reading the payload: fast, works for any protocol, cannot route by URL. Layer 7 reads HTTP requests, so it can route by path or header, retry, and insert headers, at the cost of parsing each request and terminating TLS.

API gateway vs service mesh?

A gateway handles traffic entering the system from outside (north-south): consumers, keys, quotas. A service mesh handles traffic between internal services (east-west): mutual TLS, retries, per-call metrics, usually through a sidecar proxy next to each service. Large systems often have both.

API gateway vs backend for frontend (BFF)?

A BFF is a gateway dedicated to one type of client and owned by that client's team, so the web app and the mobile app each get an API shaped for them. A single shared gateway is simpler to run; BFFs stop one client's needs from bloating everyone's gateway.

7

Your turn

60-second self-check

Your service runs on two VMs behind one domain. A teammate proposes adding an API gateway "because microservices use one". What do you say?

Stuck? Take one hint at a time0 of 2 used
0 / 25 characters
8

Learn it from the source

Related concepts

Reverse proxies and gatewaysLoad balancingRate limitingAuthentication, authorization and secrets

All concepts on one page: system design cheat sheet