Limite de requisições

Para que limitar

Uma API tem capacidade finita: CPU, conexões com o banco, chamadas a serviços externos. Sem nenhum limite, essa capacidade é dividida por ordem de chegada, e quem chega com mais pedidos leva tudo.

O limite de requisições (rate limiting) define quanto cada cliente pode usar num intervalo e recusa o excesso. A resposta padrão é o código 429 Too Many Requests, com a indicação de quando tentar de novo.

Quem é "o cliente"

Antes do algoritmo, a decisão é o que identifica cada cliente:

Os algoritmos

Janela fixa

O mais simples: um contador por cliente e por intervalo, como "pedidos do cliente 42 no minuto 14:05". Quando o minuto vira, o contador recomeça.

O problema está na virada. Um cliente pode usar o limite inteiro no fim de uma janela e o limite inteiro no começo da seguinte. Testamos com um limite de 10 pedidos por segundo, guardado no Redis: 10 pedidos aos 0,9 segundo e 10 aos 0,05 do segundo seguinte. Os 20 foram aceitos, num intervalo de 0,11 segundo, o dobro do limite.

Janela deslizante

Conta os pedidos dos últimos N segundos a partir de agora, e não do início do minuto. Elimina o problema da virada. A versão exata guarda o horário de cada pedido; a versão aproximada combina o contador da janela atual com uma fração da anterior, com memória fixa.

Balde de fichas

Cada cliente tem um balde com uma capacidade de fichas. Cada pedido gasta uma ficha. O balde é reabastecido num ritmo constante, até encher. Sem fichas, o pedido é recusado.

capacidade 10, reposição de 5 fichas por segundo

t = 0,0 s   balde cheio (10)  →  rajada de 20 pedidos: 10 aceitos, 10 recusados
t = 1,0 s   balde com 5       →  10 pedidos: 5 aceitos, 5 recusados

O balde permite rajadas curtas, até a capacidade, mas limita o ritmo médio. É o comportamento que a maioria das APIs quer: um cliente que carrega uma tela com 8 chamadas de uma vez não deve ser punido, mas não pode manter esse ritmo para sempre. Foi esse o algoritmo implementado e testado nas cinco linguagens, com o resultado exato do diagrama acima.

O problema das várias instâncias

Com a aplicação em várias cópias, como no tópico de escalabilidade, o contador precisa ser compartilhado. Um limite guardado na memória de cada instância é um limite por instância.

Testamos com duas cópias de um servidor atrás de um Nginx, cada uma com um limite de 10 pedidos por minuto na própria memória. De 30 pedidos do mesmo cliente, 20 foram aceitos: 10 por instância. Com dez instâncias, o limite efetivo seria dez vezes o configurado, e mudaria a cada escala automática.

A solução é guardar a contagem num lugar compartilhado, quase sempre o Redis.

Conferir e depois somar não funciona

A implementação mais intuitiva no Redis lê o contador, confere se está abaixo do limite e grava o novo valor. Com pedidos simultâneos, todos leem o mesmo valor antes de qualquer um gravar.

Testamos com 20 pedidos simultâneos e um limite de 10:

É a mesma lição do tópico de transações e do de idempotência: conferir e agir precisam ser uma única operação atômica. No Redis, isso significa um comando atômico como INCR ou um script Lua, que o Redis executa sem intercalar com outros comandos.

Por que isso importa quando a IA escreve o código

Um assistente que acrescenta limite de requisições costuma escolher o caminho mais curto:

• Um contador num mapa em memória, que vira um limite por instância.
• Janela fixa, com o dobro do limite na virada.
• GET e SET separados no Redis, que deixam passar rajadas simultâneas.
• Identificação pelo IP lido de X-Forwarded-For sem conferir se veio do proxy, permitindo que qualquer um troque de "identidade" a cada pedido.
• Resposta 429 sem dizer quando tentar de novo, e clientes que tentam de novo na hora.

O próximo nível compara onde aplicar o limite, quais valores escolher e como comunicar a recusa.