API Gateway vs load balancer: diferenças

Os dois ficam na frente da sua API, recebem as requisições antes do código e repassam adiante. Por isso são confundidos o tempo todo. A diferença está na pergunta que cada um responde: o load balancer pergunta "qual cópia da aplicação atende isso?", e o API gateway pergunta "esta chamada pode passar, e para qual serviço ela vai?".

Entender essa separação evita dois erros comuns: colocar um gateway pesado numa API que só precisava de duas instâncias, ou esperar de um load balancer regras de autenticação e cotas que ele não aplica.

O que é um load balancer?#

Segundo a documentação do Elastic Load Balancing da AWS, um load balancer distribui o tráfego recebido entre vários destinos, monitora a saúde deles e envia requisições só para os saudáveis. O objetivo é disponibilidade e capacidade: se uma instância cai, as outras seguem atendendo.

Ele trabalha com instâncias equivalentes. Todas rodam o mesmo código e qualquer uma pode responder qualquer requisição. A decisão é sobre carga, não sobre conteúdo. Dependendo da camada, ele enxerga só conexões TCP (camada 4) ou também o conteúdo HTTP (camada 7). Para os algoritmos de distribuição, veja algoritmos de balanceamento de carga e o artigo o que é um load balancer.

O que é um API gateway?#

Um API gateway é a porta de entrada das chamadas à API. A documentação do Amazon API Gateway o descreve como a camada que cuida de gerenciamento de tráfego, autorização e controle de acesso, monitoramento e versionamento de APIs. O Kong Gateway, outro exemplo, é um proxy reverso com plugins de autenticação e de limite de taxa por IP, chave de API ou consumidor.

Ele trabalha com serviços diferentes. Uma rota /usuarios vai para um serviço, /pedidos para outro, e cada rota pode ter regras próprias: exigir um token, aceitar 100 chamadas por minuto, ser exposta só a parceiros. Ele concentra num só lugar as políticas aplicadas a quem consome a API.

Quais são as diferenças na prática?#

As funções se sobrepõem em dois pontos. Muitos load balancers de camada 7 roteiam por caminho (/api/* para um grupo, /site/* para outro), e quase todo gateway balanceia entre as instâncias de cada serviço. Por isso, "load balancer" e "API gateway" descrevem o papel principal de uma peça, não um produto.

Quando usar um load balancer?#

Use quando a mesma API precisa de mais de uma instância:

• uma instância não aguenta o pico de requisições;
• você quer reiniciar uma instância sem derrubar o serviço inteiro;
• você quer que a falha de um processo não deixe a API fora do ar.

Um exemplo mínimo em NGINX, que usa Round Robin por padrão (segundo a documentação, não há diretiva para ativá-lo):

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

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

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

Para trocar o algoritmo, basta uma linha dentro do upstream, como least_conn; ou ip_hash;.

Quando usar um API gateway?#

Use quando a pergunta deixa de ser "como divido a carga" e vira "como controlo quem usa o quê":

• você tem vários serviços e quer um único endereço público para todos;
• consumidores externos precisam de chave de API, cota ou plano diferente;
• você quer autenticar, medir e limitar em um lugar só, em vez de repetir o código em cada serviço;
• precisa publicar versões diferentes da API lado a lado.

Para uma API única, o primeiro passo costuma ser o limite de taxa no próprio proxy. Com o módulo limit_req do NGINX:

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

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

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

Cada IP recebe 10 requisições por segundo, com uma rajada tolerada de até 20. Com nodelay, as requisições da rajada são atendidas na hora; sem ele, seriam atrasadas para caber na taxa. O que passar disso recebe resposta de erro (503 por padrão, ajustável com limit_req_status). Isso já é uma função de gateway, feita por um proxy comum. Quando você precisar de cota por chave de API, planos e painel de uso, é hora de olhar para um gateway de verdade.

Dá para usar os dois juntos?#

Sim, e é o desenho mais comum em sistemas com vários serviços:

1. Um load balancer recebe o tráfego público e o espalha entre as instâncias do gateway, para o gateway não ser um ponto único de falha.
2. O gateway autentica, aplica limites e escolhe o serviço pela rota.
3. Cada serviço tem as suas próprias instâncias, balanceadas por trás do gateway.

Em uma API só, é comum ter apenas o primeiro item: um load balancer na frente de duas ou mais instâncias, com autenticação e limite de taxa dentro do código. Por baixo, os dois papéis são exercidos por um proxy reverso. Antes de pôr uma API em produção, confira o checklist de API em produção.

Como fazer isso na Square Cloud#

Na Square Cloud, o balanceamento de carga é um recurso da plataforma: você coloca o mesmo domínio personalizado em duas ou mais aplicações. A distribuição é round-robin com failover passivo, sem health check ativo e sem sticky session. Cada aplicação tem o próprio disco, então sessão e estado vão para um banco ou Redis. O limite de aplicações por domínio depende do plano: 2 no Standard, 5 no Pro e 10 no Enterprise. Não há cobrança por requisição, e o recurso só funciona com domínio personalizado (a partir do Standard), não com o subdomínio *.squareweb.app.

Todos os planos incluem WAF, proteção DDoS L3/L4/L7 e TLS automático. Regras de gateway, como validar a chave de API ou aplicar cotas por cliente, ficam no código da sua API, com as bibliotecas do seu runtime.

A escala horizontal é manual: não há autoscaling, então você decide quantas aplicações entram no domínio. Para ver como hospedar a API e quais runtimes estão disponíveis, acesse hospedagem de APIs.