O que é rate limiting? Guia simples para criadores de apps

Rate limiting é uma regra que limita quantos pedidos alguém pode fazer a um sistema num determinado período de tempo, por exemplo 5 tentativas de login por minuto ou 100 chamadas de API por hora. Quando o limite é atingido, os pedidos seguintes são recusados (normalmente com o código de erro 429 Too Many Requests) até a janela de tempo ser reiniciada. Protege as apps contra abusos, impede que um utilizador muito intensivo abrande tudo para os restantes e trava custos descontrolados.

Vais encontrar o rate limiting de dois lados: os serviços que chamas limitam-te a ti, e a tua própria app deve limitar os seus utilizadores.

Porque é que o rate limiting importa quando crias com IA

As apps criadas com IA ligam-se muitas vezes a serviços pagos (modelos de IA, email, SMS, mapas), e cada chamada custa dinheiro. Por isso, o rate limiting é ao mesmo tempo uma funcionalidade de segurança e uma funcionalidade de orçamento.

• Controlo de custos. Se a tua app tem uma caixa de «pergunta à IA» e não tem limite, um bot pode enviar milhares de pedidos durante a noite. Pagas por cada um.
• Segurança. Sem um limite no formulário de login, um atacante pode testar milhares de palavras-passe numa conta. Um limite de algumas tentativas por minuto torna isso impraticável.
• Manter-se online. Um único script mal comportado (por vezes o teu próprio código preso num ciclo) pode sobrecarregar a base de dados e deixar a app em baixo.
• Respeitar os limites de outros serviços. Quando a tua app chama uma API externa com demasiada frequência, tu recebes os erros 429, e as funcionalidades falham para os teus utilizadores.

Os criadores de apps com IA constroem o que pedires. Se não mencionares limites, normalmente ficam de fora.

Uma analogia do dia a dia

Pensa na política de recargas grátis de uma cafetaria: «Uma recarga grátis por cliente e por visita.»

• Não impede ninguém de desfrutar do café.
• Impede que uma pessoa esteja no balcão o dia todo a encher uma garrafa para o escritório inteiro.
• Quando alguém pede uma quarta recarga, o empregado diz educadamente «não, agora não» — isso é o 429.

Um bom limite de taxa é invisível para os clientes normais e só é notado por quem está a fazer algo fora do normal.

Como funciona o rate limiting

Um limitador de taxa precisa de três coisas:

Quando chega um pedido, a app verifica a contagem para esse «quem». Abaixo do limite: o pedido passa e a contagem sobe. Acima do limite: o pedido é recusado.

Há algumas formas comuns de contar:

As contagens têm de ser guardadas num sítio rápido e partilhado. Num pequeno servidor único, a memória serve. Quando a app corre em várias máquinas, o contador costuma ficar numa loja partilhada, como o Redis ou a base de dados; caso contrário, cada máquina conta à sua maneira e o limite real fica várias vezes superior.

Como é uma resposta limitada

Quando um pedido ultrapassa o limite, uma API bem construída responde com:

• Código de estado 429 Too Many Requests.
• Muitas vezes um cabeçalho Retry-After, que indica quantos segundos esperar.
• Por vezes cabeçalhos que mostram o teu limite e quantos pedidos ainda tens nesta janela (os nomes variam conforme o fornecedor).

A tua app deve responder a um 429 esperando e tentando mais tarde, idealmente com backoff exponencial, que significa esperar um pouco mais após cada tentativa falhada (1 segundo, depois 2, depois 4) em vez de martelar o serviço.

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

Suponhamos que criaste uma app em que os utilizadores colam texto e recebem uma reescrita feita pela IA.

Sem limites: alguém escreve um script que envia 20.000 pedidos durante a noite. A fatura do teu fornecedor de IA dispara, e a tua conta atinge o limite de taxa do próprio fornecedor, por isso os utilizadores reais veem erros durante toda a manhã.

Com limites sensatos:

1. Por utilizador autenticado: 30 reescritas por hora no plano gratuito, 300 nos planos pagos. Acima do limite, o utilizador vê: «Atingiste o limite desta hora. Tenta de novo daqui a 12 minutos, ou faz upgrade.»
2. Por endereço IP no formulário de registo: 5 registos por hora, para impedir bots de criar milhares de contas gratuitas e contornar o limite por utilizador.
3. Um limite de gastos definido no painel do teu fornecedor de IA, como última linha de defesa caso tudo o resto falhe.
4. Tratar os limites do fornecedor: se o fornecedor de IA devolver um 429, o teu servidor espera e tenta de novo uma ou duas vezes, e depois mostra uma mensagem amigável de «ocupado, tenta de novo».

Os limites são verificados no servidor. Um limite que existe apenas no browser, por exemplo desativar o botão depois de 30 cliques, pode ser contornado por qualquer pessoa que chame a tua API diretamente.

Termos-chave

Erros comuns e ideias erradas

• «O rate limiting só serve para apps grandes.» As apps pequenas também são alvos, porque os bots analisam a internet inteira à procura de formulários e endpoints de IA abertos. O custo do abuso não depende do tamanho da tua app.
• «Esconder o botão basta.» Os limites no browser são uma cortesia, não uma proteção. Os limites reais têm de ser aplicados no servidor.
• «Os limites por IP são sempre justos.» Muitas pessoas podem partilhar o mesmo endereço IP: um escritório, uma escola, uma rede móvel. Os limites por utilizador são mais justos quando as pessoas têm sessão iniciada.
• «Um 429 significa que o serviço está avariado.» Significa que estás a chamá-lo com demasiada frequência. Verifica o teu código à procura de ciclos e guarda em cache os resultados que não mudam com frequência; vê o que é cache.
• «O rate limiting substitui um limite de gastos.» Usa os dois. Os limites da app podem ter erros; o limite de gastos do fornecedor é a tua rede de segurança.

O que pedir ao teu criador de apps com IA

• «Adiciona rate limiting no servidor ao login, ao registo, à recuperação de palavra-passe e ao endpoint de IA. Sugere limites sensatos.»
• «Limita cada utilizador autenticado a [N] pedidos de IA por hora e mostra uma mensagem clara com o tempo de espera quando atingir o limite.»
• «Quando uma API externa devolver 429, tenta de novo com backoff exponencial até 3 vezes e depois mostra um erro amigável.»
• «Onde são guardados os contadores do rate limit? Continuam a funcionar se a app correr em mais do que uma máquina?»
• «Regista sempre que um utilizador ou IP atinge um limite, para eu conseguir detetar abusos.»
• «Que serviços externos esta app chama, e quais são os limites deles?»

Rate limiting na Mythex

A documentação da Mythex é direta sobre isto nas funcionalidades de IA: os limites de taxa, a segurança e os controlos de custos nas apps que crias são da tua responsabilidade. Vê Criar uma app de IA. Pede ao agente que adicione limites na mesma mensagem em que pedes a funcionalidade. No plano Pro, um serviço publicado pode correr em até três máquinas quando o tráfego é intenso (vê Limites de alojamento), por isso pede contadores guardados na base de dados e não na memória de um único servidor.

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

Perguntas