O que é limitação de taxa (rate limiting)? Um guia em linguagem simples para criadores de apps

Rate limiting é uma regra que limita quantas requisições alguém pode fazer a um sistema em um determinado intervalo de tempo, por exemplo, 5 tentativas de login por minuto ou 100 chamadas de API por hora. Quando o limite é atingido, as requisições seguintes são recusadas (geralmente com o código de erro 429 Too Many Requests) até a janela de tempo ser reiniciada. Ele protege os apps contra abuso, impede que um usuário muito intenso deixe tudo lento para os demais e evita custos descontrolados.

Você encontra rate limiting de dois lados: os serviços que você chama limitam você, e o seu próprio app deve limitar os seus usuários.

Por que o rate limiting importa quando você cria com IA

Apps criados com IA costumam se conectar a serviços pagos, como modelos de IA, e-mail, SMS e mapas, e cada chamada custa dinheiro. Isso faz do rate limiting tanto um recurso de segurança quanto um recurso de controle de orçamento.

• Controle de custos. Se o seu app tem uma caixa “pergunte à IA” e não tem limite, um bot pode enviar milhares de requisições durante a noite. Você paga por cada uma.
• Segurança. Sem um limite no formulário de login, um atacante pode testar milhares de senhas em uma conta. Um limite de poucas tentativas por minuto torna isso inviável.
• Continuar no ar. Um único script com defeito, às vezes o seu próprio código preso em um loop, pode sobrecarregar o banco de dados e derrubar o app.
• Respeitar os limites de outros serviços. Quando o seu app chama uma API externa com frequência demais, você recebe os erros 429, e os recursos quebram para os seus usuários.

Criadores com IA vão construir o que você pedir. Se você não mencionar limites, eles costumam ficar de fora.

Uma analogia do dia a dia

Pense na política de reposição grátis de uma cafeteria: “Uma reposição grátis por cliente por visita.”

• Ela não impede ninguém de aproveitar o café.
• Ela impede que uma pessoa fique no balcão o dia todo reabastecendo uma garrafa para o escritório inteiro.
• Quando alguém pede uma quarta reposição, o atendente diz educadamente “agora não” — isso é o 429.

Um bom limite de taxa é invisível para clientes normais e só é percebido por quem faz algo fora do comum.

Como o rate limiting funciona

Um limitador de taxa precisa de três coisas:

Quando uma requisição chega, o app verifica a contagem desse “quem”. Abaixo do limite: a requisição passa e a contagem sobe. Acima do limite: a requisição é recusada.

Há alguns métodos comuns de contagem:

As contagens precisam ser guardadas em algum lugar rápido e compartilhado. Em um servidor pequeno, a memória funciona. Quando o app roda em várias máquinas, o contador normalmente fica em um armazenamento compartilhado, como o Redis ou o banco de dados; caso contrário, cada máquina conta por conta própria e o limite real fica várias vezes maior.

Como é uma resposta limitada por taxa

Quando uma requisição passa do limite, uma API bem configurada responde com:

• Código de status 429 Too Many Requests.
• Geralmente um cabeçalho Retry-After, indicando quantos segundos esperar.
• Às vezes, cabeçalhos mostrando o seu limite e quantas requisições restam nesta janela (os nomes variam conforme o provedor).

O seu app deve responder a um 429 esperando e tentando de novo mais tarde, idealmente com backoff exponencial, ou seja, esperando um pouco mais após cada tentativa falha (1 segundo, depois 2, depois 4), em vez de martelar o serviço.

Um exemplo prático: um assistente de escrita com IA

Suponha que você criou um app em que os usuários colam um texto e recebem uma reescrita feita por IA.

Sem limites: alguém escreve um script que envia 20.000 requisições durante a noite. A conta do seu provedor de IA dispara, e a sua conta bate no limite de taxa do próprio provedor, então os usuários reais veem erros a manhã toda.

Com limites sensatos:

1. Por usuário conectado: 30 reescritas por hora no plano gratuito, 300 nos planos pagos. Acima do limite, o usuário vê: “Você atingiu o limite desta hora. Tente novamente em 12 minutos ou faça upgrade.”
2. Por endereço IP no formulário de cadastro: 5 cadastros por hora, para impedir que bots criem milhares de contas gratuitas e contornem o limite por usuário.
3. Um teto de gastos definido no painel do seu provedor de IA, como última linha de defesa caso tudo mais falhe.
4. Lidar com os limites do provedor: se o provedor de IA retornar um 429, o seu servidor espera e tenta uma ou duas vezes mais, e depois mostra uma mensagem amigável de “ocupado, tente novamente”.

Os limites são verificados no servidor. Um limite que existe apenas no navegador, por exemplo, desativar o botão após 30 cliques, pode ser contornado por qualquer pessoa que chame a sua API diretamente.

Termos principais

Equívocos comuns

• “Rate limiting é só para apps grandes.” Apps pequenos também são alvos, porque bots varrem a internet inteira em busca de formulários abertos e endpoints de IA. O custo do abuso não depende do tamanho do seu app.
• “Esconder o botão já basta.” Limites do lado do navegador são uma cortesia, não uma proteção. Os limites reais precisam ser aplicados no servidor.
• “Limites por IP são sempre justos.” Muitas pessoas podem compartilhar um mesmo IP, como um escritório, uma escola ou uma rede móvel. Limites por usuário são mais justos quando as pessoas estão conectadas.
• “Um 429 significa que o serviço está quebrado.” Significa que você está chamando o serviço com frequência demais. Verifique se o seu código tem loops e guarde em cache os resultados que mudam pouco; veja o que é cache.
• “Rate limiting substitui um teto de gastos.” Use os dois. Os limites do seu app podem ter bugs; o teto de gastos do provedor é o seu plano de contingência.

O que pedir ao seu criador de apps com IA

• “Adicione rate limiting no servidor para login, cadastro, redefinição de senha e o endpoint de IA. Sugira limites sensatos.”
• “Limite cada usuário conectado a [N] requisições de IA por hora, e mostre uma mensagem clara com o tempo de espera quando ele atingir o limite.”
• “Quando uma API externa retornar 429, tente de novo com backoff exponencial até 3 vezes e depois mostre um erro amigável.”
• “Onde os contadores de rate limit são armazenados? Eles continuam funcionando se o app rodar em mais de uma máquina?”
• “Registre sempre que um usuário ou IP atingir um limite, para que eu consiga identificar abusos.”
• “Quais serviços externos este app chama, e quais são os limites de taxa deles?”

Rate limiting no Mythex

A documentação do Mythex é direta sobre isso para recursos de IA: limites de taxa, segurança e controles de custo nos apps que você cria são de sua responsabilidade e devem ser planejados por você; veja Criar um app de IA. Peça ao agente para adicionar limites na mesma mensagem em que você pede o recurso. No plano Pro, um serviço publicado pode rodar em até três máquinas quando o tráfego estiver alto (veja Limites de hospedagem), então peça contadores que fiquem no banco de dados, e não na memória de um único servidor.

Leitura relacionada: o que é uma API, como usar APIs de LLM e a lista de verificação de segurança para apps criados com IA.

Perguntas