API gateway vs load balancer

Both sit in front of your API, receive requests before your code does and pass them along. That is why they get mixed up. The difference is the question each one answers: the load balancer asks "which copy of the app handles this?", and the API gateway asks "can this call go through, and which service does it go to?".

Getting this right avoids two common mistakes: putting a heavy gateway in front of an API that only needed two instances, or expecting a load balancer to enforce authentication and quotas it does not apply.

What is a load balancer?#

According to the AWS Elastic Load Balancing documentation, a load balancer distributes incoming traffic across multiple targets, monitors their health and sends requests only to the healthy ones. The goal is availability and capacity: if one instance dies, the others keep serving.

It works with equivalent instances. They all run the same code and any of them can answer any request. The decision is about load, not content. Depending on the layer, it sees only TCP connections (layer 4) or the HTTP content too (layer 7). For distribution algorithms, see load balancing algorithms and what is a load balancer.

What is an API gateway?#

An API gateway is the front door for API calls. The Amazon API Gateway documentation describes it as the layer that handles traffic management, authorization and access control, monitoring and API version management. Kong Gateway, another example, is a reverse proxy with plugins for authentication and for rate limiting by IP, API key or consumer.

It works with different services. A /users route goes to one service, /orders to another, and each route can have its own rules: require a token, accept 100 calls per minute, be exposed only to partners. It gives you one place to enforce policy on everyone who consumes the API.

What are the practical differences?#

The features overlap in two places. Many layer 7 load balancers route by path (/api/* to one group, /site/* to another), and almost every gateway balances across the instances of each service. So "load balancer" and "API gateway" describe a component's primary role, not a product.

When should you use a load balancer?#

Use one when the same API needs more than one instance:

• a single instance cannot handle the request peak;
• you want to restart an instance without taking the whole service down;
• you want a crashed process not to put the API offline.

A minimal NGINX example, which uses Round Robin by default (per the docs, there is no directive to enable it):

upstream api {
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
}

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://api;
    }
}

To change the algorithm, add one line inside upstream, such as least_conn; or ip_hash;.

When should you use an API gateway?#

Use one when the question stops being "how do I split the load" and becomes "how do I control who uses what":

• you have several services and want one public address for all of them;
• external consumers need different API keys, quotas or plans;
• you want to authenticate, measure and limit in one place instead of repeating code in every service;
• you need to publish different API versions side by side.

For a single API, the first step is usually rate limiting at the proxy itself. With NGINX's limit_req module:

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

server {
    listen 80;
    server_name api.example.com;

    location / {
        limit_req zone=perip burst=20 nodelay;
        proxy_pass http://api;
    }
}

Each IP gets 10 requests per second, with a tolerated burst of up to 20. With nodelay, burst requests are served right away; without it, they would be delayed to fit the rate. Anything beyond that gets an error response (503 by default, adjustable with limit_req_status). That is already a gateway function, done by an ordinary proxy. When you need quotas per API key, plans and a usage dashboard, it is time to look at a real gateway.

Can you use both together?#

Yes, and it is the most common layout in multi-service systems:

1. A load balancer takes the public traffic and spreads it across the gateway instances, so the gateway is not a single point of failure.
2. The gateway authenticates, applies limits and picks the service by route.
3. Each service has its own instances, balanced behind the gateway.

For a single API, you often have only the first piece: a load balancer in front of two or more instances, with authentication and rate limiting inside the code. Under the hood, both roles are played by a reverse proxy. Before putting an API in production, check the API production checklist.

How to do this on Square Cloud#

On Square Cloud, load balancing is a platform feature: you put the same custom domain on two or more applications. Distribution is round-robin with passive failover, with no active health check and no sticky sessions. Each application has its own disk, so sessions and state go to a database or Redis. The number of applications per domain depends on the plan: 2 on Standard, 5 on Pro and 10 on Enterprise. There is no per-request charge, and it only works with a custom domain (from Standard), not with the *.squareweb.app subdomain.

Every plan includes a WAF, L3/L4/L7 DDoS protection and automatic TLS. Gateway rules, such as validating the API key or applying per-customer quotas, live in your API's code, using your runtime's libraries.

Horizontal scaling is manual: there is no autoscaling, so you decide how many applications join the domain. To see how to host the API and which runtimes are available, read API hosting.