Proteja serviços com rate limiting

Um limitador de taxa (rate limiter) restringe quantas requisições um cliente (por usuário, chave de API ou IP) pode fazer num período. Ele protege os serviços contra abuso e sobrecarga, garante uso justo e níveis de preço, e limita o estrago de um cliente com bug. Requisições rejeitadas recebem HTTP 429 Too Many Requests, de preferência com um cabeçalho Retry-After.

• Contador de janela fixa: conta as requisições por janela do relógio (por exemplo, por minuto). Simples e barato, mas um cliente pode mandar o limite inteiro no fim de uma janela e outro limite no início da próxima - cerca de 2× num curto intervalo.
• Log de janela deslizante: guarda o timestamp de cada requisição e conta as que estão dentro da última janela. Preciso, mas a memória cresce com o tráfego.
• Contador de janela deslizante: combina as contagens da janela atual e da anterior. Uma aproximação boa e barata.
• Token bucket: um balde guarda até capacidade tokens e é reabastecido a uma taxa constante. Cada requisição gasta um token. A capacidade define o pico permitido; a taxa de reabastecimento define a vazão sustentada.

Um exemplo: com limite de 3 por minuto, requisições nos segundos 1, 2, 2, 3 e 3 resultam em três permitidas e duas rejeitadas. Uma requisição no segundo 61 cai na janela seguinte, então é permitida.

Com muitos servidores de API, o contador local de cada servidor só vê parte do tráfego. Um limitador distribuído guarda os contadores num armazenamento compartilhado e rápido, como o Redis, usando operações atômicas (INCR com expiração, ou um script Lua para um token bucket) para que requisições concorrentes não entrem em condição de corrida. Os limitadores costumam ficar num API gateway ou num middleware e, se o armazenamento cair, devem falhar aberto ou fechado de forma deliberada.