Limitação de Taxa de API

A limitação de taxa é implementada através de vários algoritmos, cada um com diferentes compensações. Janela Fixa (Fixed Window): conta requisições por janela definida (por exemplo, 1.000 requisições por hora). Simples, mas vulnerável a picos nos limites da janela. Janela Deslizante (Sliding Window): uma janela de tempo contínua (por exemplo, 1.000 requisições em qualquer período de 60 minutos) elimina picos nos limites. Balde de Tokens (Token Bucket): clientes acumulam "tokens" a uma taxa constante até um máximo, e cada requisição custa um token. Permite tráfego em rajadas até o tamanho do balde, enquanto impõe limites médios sustentados — o mais próximo dos padrões de uso do mundo real. Balde Furado (Leaky Bucket): processa requisições a uma taxa fixa, enfileirando requisições em excesso — suaviza o tráfego completamente, mas introduz latência durante rajadas. A maioria das plataformas SaaS usa Balde de Tokens ou Janela Deslizante porque equilibram a flexibilidade para padrões de uso legítimos em rajadas com a proteção contra abuso sustentado ou código descontrolado.

Erros de limite de taxa (HTTP 429 "Too Many Requests") são frequentemente diagnosticados erroneamente como bugs, em vez de comportamento esperado da API. O suporte deve: primeiro, verificar se o cliente está realmente excedendo o limite de taxa de seu plano (verificar dados de uso da API no painel de administração); educar sobre a resposta 429 e seu cabeçalho 'retry-after' (a resposta da API inclui o tempo até que a próxima requisição seja aceita — clientes corretos devem implementar 'exponential backoff' ao receber 429s, em vez de tentar novamente imediatamente); investigar se a implementação do cliente está lidando corretamente com os limites de taxa (muitos bugs de integração vêm de loops de 'retry' infinitos que pioram o problema do limite de taxa); determinar se o cliente tem uma necessidade legítima de um limite de taxa mais alto (um cliente empresarial cujo caso de uso requer maior throughput pode justificar um limite personalizado ou um upgrade de plano); e documentar sistematicamente as perguntas sobre limite de taxa para informar se os limites de nível de plano são apropriados ou precisam de ajuste.

Os limites de taxa são uma decisão de design de produto e comercial, não apenas uma restrição técnica. A Product Ops deve garantir que os limites de taxa sejam: documentados explicitamente na referência pública da API (incluindo limites por endpoint, não apenas limites globais); diferenciados por nível de preço (clientes de planos superiores recebem limites mais altos — isso cria um benefício concreto e tangível para upgrades); exibidos em tempo real através de um painel de uso no produto (os clientes devem ser capazes de ver seu consumo atual em relação ao seu limite, com alertas antes de atingirem o teto); e acompanhados por um caminho de upgrade claro (um banner ou e-mail acionado quando um cliente atinge 80% de seu limite de taxa os direciona para fazer um upgrade, em vez de simplesmente falhar com 429s). Upgrades impulsionados por limites de taxa são um motor de receita de expansão mensurável que a Product Ops rastreia juntamente com outros gatilhos de expansão.